heyman / heynote

A dedicated scratchpad for developers
https://heynote.com
Other
3.94k stars 195 forks source link

Feature Request: VIM keymap #24

Open carsondoesbusiness opened 9 months ago

carsondoesbusiness commented 9 months ago

Please include VIM key mapping!

nilsherzig commented 9 months ago

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

https://github.com/heyman/heynote/blob/a871291ec68daee9aa7cf3402ce99a2ae452a8bf/src/editor/editor.js#L24-L30

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

heyman commented 9 months ago

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 commented 9 months ago

Would love to see it :)

tarasowski commented 9 months ago

bump!

brendanbond commented 9 months ago

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 commented 8 months ago

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 commented 8 months ago

@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