Adding command support for minor modes

[CyberFlaw]

As we know all the helix work on commands. We enter into some mode and do some keybinding which results in executing a command like hover for C-k in normal mode.

While I was fiddling with the config file, I noticed I can't remap w in space mode (or C-w) to any other key as there are no commands for selecting or moving to another mode (except for non-minor modes).

I'd like to propose an idea to add commands for minor modes so we can remap window or similar modes like goto, view, or sticky view with other keybindings from the config file itself, and not tweak the source code for default keymap

[pascalkuthe]

The basic problem you are describing is #5505 so I am closing this as a duplicate of that. You can add your ideas for fixing that as a comment to that issue

[the-mikedavis]

Actually it looks to me like this is about being able to remap minor modes like <space>w than remapping commands on components. I doubt that we would want to refactor minor modes so that they're commands (because they are not commands, just special states in the keymap structure) but I will leave this open for ideas on making it easier to remap minor modes.

[7ombie]

TLDR: I'm just sharing an opinion on how bindings aught to work. If you're busy, you can ignore this.

Default bindings should just be a default config that's bundled with Helix (so the user can always redefine them). It'd be helpful if config/keybinding files could inherit/include other files (similar to the way themes can), so users can customize an existing config, or just nuke everything and start from scratch.

Ideally, we'd be able to add, remove and modify commands in minor modes, edit the description of a command, reorder the commands in the menu, rename the mode, as well as create new, named minor modes (so Helix shows the name above the new mode's menu). The documented minor modes would also just be part of the default config.

I'm not sure how realistic that is, but think that kind of customization would be good for Helix adoption.

A lot of programmers have accessibility limitations that make it impossible to touch-type, and many others just don't want to touch-type (whether they aught to or not). This makes a huge difference. If you type often, but don't touch-type, the easiest keys to find (without looking) are around the edges, especially keys at the corners. The cursor keys are the easiest of all, so it's much faster, more intuitive and more consistent (for us) to always use cursor keys to navigate (than to learn to use hjkl).

Once you stop using hjkl for moving around, you can, for example, use l for selecting lines (and L to select above), which frees up x for something else, and so on. You quickly find yourself rethinking the entire scheme.

Touch-typists also rely heavily on muscle memory, so place a lot of value in familiar, conventional bindings. The rest of us rely much more heavily on mnemonics to recall which key does what, so our priorities are all different.

I'm mindful of how long and opinionated this post has become, so will leave it here. You get the point. In an editor like Helix, being able to fully customize the keybindings is especially valuable.

[pascalkuthe]

closing in favor of #10389