Keyboard shortcuts in post editor override macOS text area keybindings

[NateEag]

On macOS, text areas support Emacs-style Control-key keybindings. That means Ctrl-p moves the cursor to the previous line, and Ctrl-b moves the cursor back one character.

In QPixel, Ctrp-p and Ctrl-b are defined as keyboard shortcuts, per this issue.

For a macOS user who has the Emacs keybindings in their muscle memory, this is very frustrating.

To Reproduce
Steps to reproduce the behavior:

1. Click on the 'Ask Question' button in a macOS web browser (I use Chrome).
2. Focus the post editor.
3. Write a few lines of text, then try pressing Ctrl-p or Ctrl-b. Delimiters are inserted.

Expected behavior

I expect macOS's native cursor movement to occur for the Ctrl-p and Ctrl-b key combinations.

Desktop:

• OS: macOS Monterey (12.3.1)
• Browser: Chrome 100.0.4896.127

Additional context

A common solution to this sort of problem is to make the Control-key shortcuts be Command-key shortcuts on macOS.

A potential issue with that approach is conflicts with existing macOS keybindings. Specifically, Command-p is reserved for printing documents, and generally there are many global and app keyboard shortcuts that could conflict with any chosen key combination.

[cellio]

Thanks for this report. I agree we want to do something to follow the norms people are used to from their platforms; I'm not sure how to address the conflicts you mentioned. I wonder what others do -- avoid the "problem" bindings entirely, use user preferences, something else? We'll need to do some research.

[NateEag]

A good-enough workaround for overriding the macOS Control key bindings might be a preference to turn off keyboard shortcuts in the editor.

I tried turning off the 'keyboard shortcuts' preference to see if it did that already, but it doesn't seem to.

Might it be reasonable to extend that preference to also turn off editor shortcuts?

That wouldn't be a general answer for making QPixel work well for macOS users, but it would address my immediate complaint, and might arguably be in line with the preference's intended purpose.

[cellio]

I think a separate preference makes sense; one might want to control using keyboard shortcuts to navigate the site (what the existing ones do) separately from using them to edit. Let's not make people give up navigation shortcuts in order to be able to use OS-native editing shortcuts.

Proposal: add a network preference called Editor Keyboard Shortcuts, default on (i.e. current behavior), right below the Keyboard Tools preference. Turning it off disables the editor shortcuts (only). Update the description of Keyboard Tools to change "Enable keyboard shortcuts" to "Enable keyboard shortcuts for site navigation".

[NateEag]

Okay, makes sense to me.

What's the process for making something like this happen? Does someone who cares enough just submit a PR, or is there more to it?

[cellio]

Yes, a PR is welcome, thanks! See https://github.com/codidact/qpixel/blob/develop/CONTRIBUTING.md for mechanics (pretty basic stuff, probably like other projects you've contributed to). We also have a project (development) DIscord server, if you're looking for help that's more interactive than GH comments -- completely optional, but here's a link in case you're interested: https://discord.gg/J6u64Ct .

As you know, there's already a network preference for the navigation keyboard preferences, so if you find the places that hook into that, you should be able to patten-match for this new one. (Of course the editor changes will be new.)