Closed eugenesvk closed 4 months ago
This is a good issue, I also find the repetition annoying, and was very confusing as a new user. I'd make a binding, and then it wouldn't work in select mode, and didn't realize that I had to repeat it in every mode. Kakoune and vim both have config options that make the binding the primary key, and you must specify the mode in which the binding works. I wonder if it would be better to change the format to something like:
[keys]
a = { action = b, modes = [ "normal", "visual" ] }
[keys.c]
action = [ "d", "e" ]
modes = [ "insert" ]
Or maybe we could even do a little custom parsing to make the format more concise:
[keys]
a.ns = b
A-c.i = [ "d", "e" ]
The more concise version is definitely better, and we might even make it behave in a way to minimize any disruption of current configs (might not be very important at this stage, but at any rate I think this might be a better way) like so:
[keys.normal] # ok to group blocks of keybinds by mode
# this will be the default for all keybinds that don't specify a mode
a = "cmd1" # works in Normal mode only, no need to change anything for current configs
b.s = "cmd2" # works in Normal mode, but also works in Select mode
A-c.si = ["cmd3","cmd4"] # works in Normal, Select, and Insert modes
Then the remapped window mode could be made identical in all modes like so:
[keys.'C-w'.nsi] # Window mode, works the same in Normal, Select, and Insert modes
'a' = 'cmd'
# ...
or like so to maintain the current logic of specifying a mode in a group? Then you could have a group of "common" keybinds at beginning of a file and then specify mode-specific ones later
[keys.NorSelIns.'C-w'] # Window mode, works the same in Normal, Select, and Insert modes
'a' = 'cmd'
# ...
I admire the care to avoid breaking changes, and normally I would agree, but in this case, helix is pretty new and doesn't make any stability guarantees, so I think now is the period of time in which iteration to "get it right" is prudent. In fact, there has been discussion in the community, and I believe from @archseer himself, that we don't want toml being the long term config format anyway. So we shouldn't be too afraid of making breaking changes at this point. And I think the logic you describe above seems more complicated than it's worth.
Yeah, the downside is that it's not always immediately obvious in large config files what mode a keybind belongs two (I've added a bunch of ⓃⓈⓘ in the #headings of keybind sub-groups to avoid confusion), so might indeed be easier to add a .n
.s
.nsi
etc. to each keybind (as long as it's not modes = [ "normal", "visual" ]
:) )
closing in favor of #10389
I've modified the default "Window command" dialog list. Now I have to copy the same commands to "Space command" as well as to the "Select mode" to have everything consistent (and also to the "Insert mode" while we're at it ;) ) And if I edit something (which is usually happening a lot in the initial learning phase) I have to repeat this process again, this is some rather cumbersome anti-DRY pattern right there!
I'd like to be able to avoid this repetition either by defining a dialog mode as kind of a command list or something and then just assign the same list in different places like "C-w", [keys.select."C-w"], [keys.insert."C-w"], [keys."space"] "w"="" etc. Then I'd only have to edit this list once and the changes will propagate everywhere it's called from