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

Port Emacs' god-mode #2510

Open
hendursaga opened this issue Aug 20, 2022 · 7 comments
Open

Port Emacs' god-mode #2510

hendursaga opened this issue Aug 20, 2022 · 7 comments
Labels
feature Feature requests. good-first-issue Marks a good issue for first-time contributors.

Comments

@hendursaga
Copy link
Contributor

god-mode is one of my favorite Emacs packages for reducing my risk of getting RSI as well as avoiding evil, and since I use Emacs-style keybindings in Nyxt, it would be nice to port some / all of the functionality over!

@hendursaga hendursaga added the feature Feature requests. label Aug 20, 2022
@Ambrevar
Copy link
Member

I believe a custom nkeymap translator should be enough to implement it.

@hendursaga
Copy link
Contributor Author

@Ambrevar I figured that would be the bulk of it.

Another problem would be keeping it tied to emacs-mode as well as what to do with passthrough-mode...

@aadcg
Copy link
Member

aadcg commented Aug 21, 2022

The first observation is that we can't afford to curate every set of keybindings, but we should provide the foundations for users to define they own and maintain external libraries.

Emacs keybindings achieve modality by pre-prending modifier keys, whereas VI keybindings are inherently modal.

god-mode, in Nyxt's parlance, would be basically a modified VI keyscheme. Am I wrong?

I'd abstract our keyschemes. We have non-modal ones (default, cua and emacs) and one modal (vi). We should make vi a particular case of a modal keyscheme, where users could choose the key to set the active mode(s) (insert, command, etc) and choose the keybindings for each mode. The way I see it, god-mode isn't the best source of inspiration here, but rather ryo-modal.

@hendursaga
Copy link
Contributor Author

The first observation is that we can't afford to curate every set of keybindings

I agree, but god-mode is essentially Emacs keybindings with shortcuts to avoid destroying your pinky finger from trying to reach the physical modifier keys. I haven't really researched ryo-modal - mostly because I found god-mode sufficient enough for myself - but looking it over, I would say it would be better inspiration, a more general approach.

@aadcg aadcg added the good-first-issue Marks a good issue for first-time contributors. label Aug 22, 2022
@aartaka
Copy link
Contributor

aartaka commented Aug 22, 2022

Huh, maybe introducing yet another layer of input management below command-dispatcher and input-skip-dispatcher could allow this extension? 🤔

Then the design would be:

  • key-dispatcher -- dispatches over the key, allowing to either
    • leave it hang as a prefix key,
    • resolve it to some action and clean the key stack,
    • replace it with some other key to send to the renderer, or
    • delegate handling to the default dispatcher.
  • Default dispatcher of this key-dispatcher would call:
    • comand-dispatcher for keys that have command keybindings.
    • input-skip-dispatcher for those that don't have bindings.

While describe-key is an extension on the level of command-dispatcher, god-mode would be a key-dispatcher extension, basically checking every key's prefixed presence in the keymaps and using its prefixed bindings if they are unambiguous.

See 309728f and the commits following it for the origins of the command-dispatcher and input-skip-dispatcher.

@Ambrevar
Copy link
Member

Ambrevar commented Sep 1, 2022

@aadcg @aartaka I don't believe we need to add anything new: nkeymap was designed to support this kind of things. Look into the key translators: it's an abstraction layer between the inputted keys and the bindings.

@aartaka
Copy link
Contributor

aartaka commented Sep 1, 2022

I see...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Feature requests. good-first-issue Marks a good issue for first-time contributors.
Development

No branches or pull requests

4 participants