Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow reusing a list of commands for dialogs #1498

Closed
eugenesvk opened this issue Jan 12, 2022 · 5 comments
Closed

Allow reusing a list of commands for dialogs #1498

eugenesvk opened this issue Jan 12, 2022 · 5 comments
Labels
A-helix-term Area: Helix term improvements C-enhancement Category: Improvements

Comments

@eugenesvk
Copy link

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

@eugenesvk eugenesvk added the C-enhancement Category: Improvements label Jan 12, 2022
@kirawi kirawi added the A-helix-term Area: Helix term improvements label Jan 12, 2022
@dead10ck
Copy link
Member

dead10ck commented Jan 15, 2022

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" ]

@eugenesvk
Copy link
Author

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'
  # ...

@dead10ck
Copy link
Member

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.

@eugenesvk
Copy link
Author

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" ] :) )

@pascalkuthe
Copy link
Member

closing in favor of #10389

@pascalkuthe pascalkuthe closed this as not planned Won't fix, can't repro, duplicate, stale Apr 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-helix-term Area: Helix term improvements C-enhancement Category: Improvements
Projects
None yet
Development

No branches or pull requests

4 participants