Feature Request: VIM keymap

[carsondoesbusiness]

Please include VIM key mapping!

[nilsherzig]

codemirror has a vim mode https://codemirror.net/5/demo/vim.html should be "easy" to implement

heynote/src/editor/editor.js

Lines 24 to 30 in a871291

	function getKeymapExtensions(editor, keymap) {
	if (keymap === "emacs") {
	return emacsKeymap(editor)
	} else {
	return heynoteKeymap(editor)
	}
	}

It might be possible to just import vim.js instead of emacs.js.

[heyman]

I'd like to have this. Implementing it should probably start with some refactoring. My Emacs keymap (it's actually just the subset of the Emacs keybindings I happen to be using) is currently a bit of a duct tape implementation. Commands should be more formalized into an internal API, and once that is in place it would be nice to have a proper UI for customizing the mapped keys.

There are implementation details that will make it non-trivial. E.g. we can't trigger copy/cut/paste commands from within the renderer so there's currently code in the Electron main process that listens for those keys (https://github.com/heyman/heynote/blob/main/electron/keymap.js). Should be solvable though.

[rdslw]

Would love to see it :)

[tarasowski]

bump!

[brendanbond]

From the draft PR:

It's likely that we need to copy these implementations into Heynote and make them block aware for the Vim mode.

It would be nice to simply "extend" the operators, so I've asked about a potential API change to the vim dependency that will hopefully allow us to make the operator aware of block state. @heyman let me know if you'd be open to this type of implementation. If the replit/codemirror-vim maintainers don't like the alterOperator API that I've proposed, we can still use the dependency (it's pretty great) and just reimplement problematic operators from scratch to be block-aware using their existing defineOperator API.

EDIT: I am perhaps going to go another direction with this, but hopefully a PR soon!

[heyman]

I saw the comment on your proposal suggesting to use changeFilter. If you explore that option, keep in mind that there are cases when deleting block separators is the desired behaviour. However, deleting part of a block separator should never be possible, so maybe one could make use of changeFilter to prevent that and cover most cases (I would have to think more about it - and probably even implement it - to know for sure though).

---

there's currently code in the Electron main process that listens for those keys

This was fixed by #133, so now all code related to the Emacs keybindings at least reside in the renderer process.

[brendanbond]

@heyman yeah that's kind of my thinking - if we find ourselves in "the middle" of a block separator (i.e. "\n") we might already know that we need to offset the entire separator

in any case, thanks for the insight! hopefully can get some time this weekend to tinker with it