#1

I’d like to propose an alternate way of handling the keyMap inside of Obsidian. Currently, there are two ways of modifying the keyMap value of CodeMirror:

Screen Shot 2021-05-15 at 12.46.36 PM
Screen Shot 2021-05-15 at 12.46.36 PM1698×436 41.1 KB

The second option only exists on Mac OS, which makes handling keyMap logic ‘simple’ on non-Mac platforms (app.vault.config.vimMode), but since Obsidian is cross platform, any plugin developer needs to account for Mac OS, so the complexity is still there no matter what.

If the keyMap option was presented as a dropdown, instead of two booleans, there would be some immediate wins from this:

  1. Any plugins that have to set up their own CodeMirror instance, or run something like a SwapDoc command, could easily set the keyMap option to match whatever the user intends it to be by reading from app.vault.config.
  2. It would eliminate the impossible to fulfill state of having both ‘Legacy Emacs-style’ and ‘Vim’ bindings enabled. The current result of having both these enabled is that ‘Vim’ mode is preferred. But that is not obvious to the end user, and only happens because of the way the logic handles the different boolean flags.

One dropdown would solve this, and give one less option to the user. This would also simplify the internal Obsidian logic, since you would just be setting a direct value. Here are some plugins that could benefit from this change:

There may be others as well.

#2

@Licat & @Silver, ping!

#3

These two options are actually completely independent - Vim keybindings completely overwrite the entire keymap that CodeMirror uses, whereas the legacy emacs binding actually changes the default keymap (for macOS) to the emacsy or emacsy-less. But again, vim bindings override everything.

#4

To add to this, putting them into a single dropdown would imply that they are related. The emacsy keybinds also aren’t available on non-mac platforms so… I don’t think that makes much sense.

#5

Maybe the easiest option is to remove the Emacs setting? I am sure there was a reason for keeping it, but it makes the logic a bit convoluted, and is confusing to the end user.

#6

It’s there because there were unhappy users who finds that some of their hotkeys conflicts with macOS’s “default” legacy emacs bindings, while other users rely on them. It’s indeed confusing to the end user - I’d rather Apple not keep around such legacy things, but alas there’s so much things we don’t have control over.

#7

Here’s one of the well written docs on the emacsy keys: (Emacs) Keyboard Shortcuts for Editing Text Fields in OS X

#8

Gross! Perhaps just an addendum to the Vim mode description would help a bit then? Or greying out the Emacs option when Vim mode is enabled (although that seems less obvious).

#9

I thought it was obvious (or if it wasn’t, then would have been easy to tell by behavior). I highly doubt anyone enabling vim mode would expect emacs keybindings (It doesn’t work in vim on macOS, does it?), and it hasn’t been a problem for people so far… I guess we could tweak the description of either field to indicate such, but again, I don’t think it’s a big deal, and no user is losing sleep because emacs bindings don’t work in vim mode.

#10

Well, inside of Emacs with Evil mode and Spacemacs you can have Emacs bindings while in insert mode … as far as inside Vim, I am not sure. I am sure it’s possible.

1 Like
#11

I’ve adjusted the wording of the emacs option to include “Not available while in Vim mode.”

1 Like
#12

Thank you!