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

WIP: Refactor/streamline keybindings #1103

Closed

Conversation

har7an
Copy link
Contributor

@har7an har7an commented Feb 23, 2022

Streamlines the way the keybindings are read. While working on #1078 I realized that a lot of the bindings are redundant/repetitions of what is already bound in normal. This also means that merely changing keybindings to switch modes in normal isn't sufficient, because the changes won't carry to other modes.

This MR attempts to changes this by always applying the keybindings from the normal mode/section to all modes. This still gives the individual modes the ability to overwrite single keybindings with custom ones where needed.

It's marked WIP because:

  1. I uncommented the tests because I didn't want to adapt those before I heard your feedback on the general idea
  2. The way its currently implemented it doesn't respect the unbinds, hence I had to exclude InputMode::Locked from taking the normal bindings. I assume that this is due to the fact that I am overwriting the bindings after the unbinds have been handled already? But I'm not quite sure about that because I find it a little hard to understand what exactly is going on in parts of the code with all the From traits and stuff. :D

Expand the documentation on some of the structs and functions to clarify
their purpose in the parsing of the keybindings configuration.
Also remove an intermediate struct once used for parsing that isn't
referenced anywhere else in the code.
in favor of using the `default()` trait.
to all other keybinds. This ensures that the user has a consistent user
experience and all the basic commands/movements (to switch modes, or the
default "Alt"-bindings) can be changed in one place.
If the need arises, specific bindings can still be overriden in the
config file on a per-mode basis, as needed.
to test the feature manually from the CLI.
because the `normal`-mode bindings are now applied by default to all
other modes, so the repetitions aren't necessary any longer.
@a-kenji
Copy link
Contributor

a-kenji commented Feb 24, 2022

Thank you for this work.

I don't think we will benefit from this keybinding change, as #1036 proposes a much better solution, IMO.

If you want to refactor the config part, I will gladly look at a refactor pr.

@har7an
Copy link
Contributor Author

har7an commented Feb 24, 2022

I don't think we will benefit from this keybinding change, as #1036 proposes a much better solution, IMO.

I don't understand how #1036 does anything to deduplicate keybindings in the configuration. Could you elaborate on that?

@a-kenji
Copy link
Contributor

a-kenji commented Feb 24, 2022

I don't understand how #1036 does anything to deduplicate keybindings in the configuration. Could you elaborate on that?

Sure!

To quote directly from #1036:

// Configuration for zellij.

modes clear-defaults=true {
  // Can also use `shared` with a list of modes to include
  shared-except "locked" "renametab" "renamepane" {
    bind "Ctrl-g" {
      SwitchToMode "Locked"
    }
    bind "Ctrl-p" {
      SwitchToMode "Pane"
    }

The shared-except configuration option would allow all modes
except for the specified modes to share configuration values.
The shared configuration options would allow all modes that are listed
to share configuration values. This would allow deduplication of keybindings in the configuration.

@har7an
Copy link
Contributor Author

har7an commented Feb 24, 2022

Hmm, I guess then #1078 is obsolete as well, right?

@a-kenji
Copy link
Contributor

a-kenji commented Feb 24, 2022

Hmm, I guess then #1078 is obsolete as well, right?

I think so, though if you think your reordering makes more sense I am happy to look over it at some point. It doesn't fundamentally change the configuration.
So the scope is somewhat limited.

@har7an
Copy link
Contributor Author

har7an commented Feb 25, 2022

Well, on to something new then...

@har7an har7an closed this Feb 25, 2022
@har7an har7an deleted the refactor/streamline-keybindings branch October 23, 2022 15:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants