Key remapping for compositor components

[the-mikedavis]

There are some prior issues on this for pickers, prompts, and popups. This issue is meant to be a tracking issue for key remapping for any Component. Ideally you should be able to remap any actions for any component (pickers, prompts, menus, etc.). I think that the solution to remapping for one component should be the same or very similar to the solution for remapping any component so this issue covers all components.

This is a little tricky implementation-wise: regular commands share the same function signature that takes a &mut Context. Component commands are currently built straight into each component. For example see scrolling a popup: https://github.com/helix-editor/helix/blob/2412f7c8374d2f6a8bfd66ecf424153a37c814bf/helix-term/src/ui/popup.rs#L186-L193

This will also take some design work to decide how the config should look. I am imagining something like:

# ~/.config/helix/config.toml
[keys.normal]
# this section already exists for regular bindings, along with keys.insert and keys.select
[keys.popup]
C-j = "scroll_popup_down"
C-k = "scroll_popup_up"
# maybe these can be namespaced, like `C-j = "popup::scroll_down"`?
[keys.picker]
C-space = "validate_picker_selection"

[goyalyashpal]

hi! would this be applicable to command output popups https://github.com/helix-editor/helix/discussions/5923#discussioncomment-4946453 too?

[the-mikedavis]

Yep, the :run-shell-command/:sh command creates a Popup element and Popups are Components

[goyalyashpal]

hey!

currently

• the keys seem to be tied to the component - so,
  • C-d works in command output popups,
  • C-n/<tab> works in picker
  • hjkl works in editor (despite having other components open)

so, this concept of being able to "remap" is there in all of the above issues,

---

but the following thing seems to be not discussed. how about having

• the ability to change the current active component
• so that some carefully selected keys (took from editor modes) work across any component as long as it's the active one?

That is, there will be 3 groups of actions for a general component:

• Normal mode: one grp for navigating between components and fields (so, similar to Tab in web browsers)
• Normal mode: other for navigating within the field (the hjkl move cursor)
• Insert mode: last group for entering text (where there's no text field, it may optionally do the "search and jump to")

[tdelabro]

I wasn't happy with the scroll-in popup keymaps, because while in insert mode, if an autocompletion popup suggestion is open, I cannot use the C-d keymap that I already remaped in [keys.insert], as it is catch by the popup component before the insert one.

So I opened my config file and typed this by instinct:

[keys.popup]
C-u = "no_op"
C-d = "no_op"
C-j = "scroll_down"
C-k = "scroll_up"

and got the following error: Failed to load config: TOML parse error at line 29, column 7 |29 | [keys.popup] | ^^^^^Invalid mode 'popup'.

I'm discovering with this issue that it is not possible yet to remap those keys, but I want to sat that your design suggestion for the config is right imo

[gabydd]

have had some more time to experiment with this, what I am currently doing is name spacing the commands by adding the module name to the start of the command so ui::picker::page_down turns into picker_page_down, I was also doing this for the command name but we could instead turn the name into page::down (one line change to the component_commands macro). To make the actual commands work I created AnyPicker and AnyMenu traits(haven't implemented commands for all the components, nor are the commands names totally correct but that should be relatively easy to fix) that have the functions needed for any command on those components. Because you can't downcast from any(the Component to a trait as far as I can tell, I made the component passed to the commands an enum so commands can match for the right component.

currently it allows remapping for the picker, buffer-picker and menu, I can implement the rest of the components if we want as well, branch is here built on the great work of @the-mikedavis : https://github.com/gabydd/helix/tree/md-compositor-key-remapping-idea

change for namespaced version of compositor command naming

```diff diff --git a/helix-term/src/commands.rs b/helix-term/src/commands.rs index ecd4ad42..b2e4fdad 100644 --- a/helix-term/src/commands.rs +++ b/helix-term/src/commands.rs @@ -209,7 +209,7 @@ macro_rules! component_commands { paste! { #[allow(non_upper_case_globals)] pub const [<$second _ $name>]: Self = Self::Component { - name: stringify!([<$second _ $name>]), + name: concat!(stringify!($second), "::", stringify!($name)), fun: $first::$second::$name, doc: $doc }; ```

[ykerit]

Really looking forward to the key bindings, when will they happen?