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

Un-default the help-mode bindings into CUA scheme #2956

Open
aartaka opened this issue May 10, 2023 · 3 comments
Open

Un-default the help-mode bindings into CUA scheme #2956

aartaka opened this issue May 10, 2023 · 3 comments
Labels
command Core functionality: commands. feature Feature requests. good-first-issue Marks a good issue for first-time contributors. help-system low modes Core functionality: modes. ui/ux Nyxt User Interface: themes, appearance and usability.

Comments

@aartaka
Copy link
Contributor

aartaka commented May 10, 2023

Is your feature request related to a problem? Please describe.
We have our help-mode with convenient navigation bindings. But I often end up opening an inspector or some other input side-by-side with our help pages, and then inputting text into these ends up invoking the help-mode commands, because these are a single-key bindings. Not cool.

Describe the solution you'd like
Let's only enable these bindings for CUA scheme, because:

  • CUA users (keyscheme discrimination? :D) are not likely to use anything alongside the manual/describe* etc.
  • Users of other schemes are not likely to use these single-key bindings, and will likely utilize their muscle memory of the respective commands instead of shortcuts.

Removing help-mode is useful, it is really (pun intended) helpful, after all. So let's just lessen the damage to Emacs/VI people :)

@aartaka aartaka added feature Feature requests. good-first-issue Marks a good issue for first-time contributors. ui/ux Nyxt User Interface: themes, appearance and usability. modes Core functionality: modes. command Core functionality: commands. help-system labels May 10, 2023
@Ambrevar
Copy link
Member

Do you have other use cases beside the inspector?

Ideally, we would differentiate the input based on the "view" that's focused, that is, if it's the web view or the inspector. But it's not very clear to me how WebKit handles this.

@aartaka
Copy link
Contributor Author

aartaka commented May 11, 2023

Do you have other use cases beside the inspector?

One day, we might have inputs in the manual. And that would break them severely.

Ideally, we would differentiate the input based on the "view" that's focused, that is, if it's the web view or the inspector. But it's not very clear to me how WebKit handles this.

It doesn't, really :(

@Ambrevar
Copy link
Member

Maybe GTK can help us here to distinguish the windows...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
command Core functionality: commands. feature Feature requests. good-first-issue Marks a good issue for first-time contributors. help-system low modes Core functionality: modes. ui/ux Nyxt User Interface: themes, appearance and usability.
Development

No branches or pull requests

3 participants