Ability to hook commands into existing contexts

[xavier630]

Currently Talon consumers can only add to the user context.

This leads to some inconsistency since the user still needs to write implementations for core contexts, say browser but whenever adding their own actions to the browser which might do something very similar to these browser implementations, these are prefixed user no matter what they are.

You end up with situations like this one in the screenshot below where you have two different classes in one file and it's somewhat unclear why the modules belong in different classes, and it's somewhat arbitrary which exact actions are pre-registered by Talon in specific contexts.

Proposal Consumers of Talon should be able to add actions to places like browser in order to make browser.do_custom_action.

Let me know if I'm misunderstanding the current approach at all 👍

[xavier630]

One concrete example is here where the new command added to the command -> action mappings doesn't look anything like the existing similar commands because it doesn't have the correct context prefix

[lunixbochs]

This is on purpose - you're not allowed to add stuff yourself to the global namespace, because that is "standardized" - everyone shares the same interface there. This means scripts written by anyone using the standard interfaces will be mostly compatible and portable. The "user" namespace is not standardized and is freely writable by anything in the user/ directory.

Down the line, we will also have per-plugin namespaces. Talon can define stuff in the various top-level namespaces, users can define stuff in the user namespace, and plugin authors can define stuff in their plugin's own namespace (e.g. plugins.vim.xyz()).

If you want more stuff in the Talon namespaces, you should put together a proposal asking for and justifying specific additions. I think @AndreasArvidsson, @pokey, and @knausj85 are interested in putting together such a proposal, so maybe you can work with them on that?

[AndreasArvidsson]

We are already working on that but due to time constrains and health issues we are still in the draft state.

The plugin namespace sounds really useful btw.

[lunixbochs]

Are you coordinating that somewhere specific? Do you have something like a google doc?

[AndreasArvidsson]

Yes we have a google spreadsheet. But we have only had one meeting so it's just an very early draft and a lot of things are not really thought through yet.

[xavier630]

Okay, sounds reasonable, let's close this 👍.

Interfaces are great and +1 to the idea. It mostly feels strange since there's not much that distinguishes the default Talon interface actions from custom community ones since they are often very similar in terms of naming, behaviour and implementation and are being implemented together and mapped to commands together.

A couple of suggestions from me:

1. A form or maybe an open spreadsheet for anyone to suggest additions to the base interface.
2. A documentation page on all possible interface values (does this already exist somewhere without needing to call actions.list() from the terminal?).

[lunixbochs]

Actions in user/ follow the same form of split interface / implementation. Module() = an interface, though you can declare default impls of actions and captures on modules for convenience.

[pokey]

Are you coordinating that somewhere specific? Do you have something like a google doc?

For posterity: https://github.com/talonvoice/talon/issues/446