Let plugins contribute menu entries (and optionally replace built-in ones)

[BjoernSchotte]

Herdr is mouse-first by design — the docs open with "click panes, drag borders, split and switch from right-click menus". But plugin actions are unreachable that way. As far as I can tell from the docs, an action can only be triggered through [[keys.command]] type = "plugin_action", herdr plugin action invoke, or a link handler. Nothing surfaces it in a menu.

So a plugin is invisible to exactly the users Herdr optimises for.

Concrete case: I wrote a small worktree picker, because New worktree pre-fills a generated name (worktree-rapid-river-6486) and there is no setting for that. On the keyboard it works well — I put it on prefix+shift+g. But right-clicking a Git workspace row still opens the built-in prompt, and there is no way to point that entry somewhere else, or to add mine next to it.

What I'd like:

1. A plugin can declare that an action belongs in a given menu, so it shows up alongside the built-in entries.
2. Optionally, an action can replace a built-in entry.

For (2) the obvious worry is plugins silently hijacking the UI — the marketplace is unreviewed, and that would be a real trust problem. So I'd expect the manifest only to declare the capability and the user to enable it in config.toml, the same way keybindings already work: the plugin offers, the user decides.

One question while I'm here: contexts = ["workspace"] appears in the manifest examples but is never explained anywhere in the docs. Is it already meant for something like this, or does it only gate applicability?

Prior art for the demand: herdr-command-palette exists purely to make plugin actions findable. That gap seems worth closing in core.

[BjoernSchotte]

See https://github.com/BjoernSchotte/herdr-worktree-picker for the plugin

[BjoernSchotte]

I went and read the 0.8.2 source to answer my own question about contexts, and it turned out to answer the menu part too.

• PluginActionContext has five variants (Global, Workspace, Tab, Pane, Selection), but the type only appears in field declarations and the manifest parser. Nothing reads it to make a decision. So right now it is inert metadata that plugin action list echoes back — which also means a plugin author can't tell it isn't doing anything yet.
• ContextMenuState::items() returns Vec<&'static str>, and the selection is dispatched by matching the literal label. A plugin-contributed entry would need a runtime string, so this isn't a missing wire-up somewhere — the signature itself would have to change.

That makes the request a bigger ask than I assumed when I wrote the post, so treat it accordingly. Not asking for a patch, just closing the loop on the question I raised.

[haoblackj]

+1, with a case for the global menu specifically.

I want to stop the server from the UI. detach is already in the global menu, but herdr server stop is only reachable from a shell. As a stopgap I wrote a small local plugin (an action that opens a y/N popup and then runs herdr server stop) and reach it through herdr-command-palette, but that is still keyboard-only.

Since PluginActionContext::Global already exists in the manifest, letting contexts = ["global"] actions appear in the global menu (settings / keybinds / reload config / detach) would cover this without any new manifest field. Opt-in from config.toml, as proposed above, would be fine.