[WIP] Support Vim mode in notebook

[parleur]

This pull request is functional but not usable right now.

It switches the keybindings of all codemirror instance (inspired by the editor). It obviously raises issue in UI interface I aim to discuss here.

• Issues (just here to be exhautive):
  • Double modal editor: when vim mode is activated in CM, it add a modal editor inside the Jupyter's modal management... Yes press Enter then press a to edit ... not usable
  • Escape (managed by Jupyter) unfocus CM even in Vim edit mode.
• Solutions proposed. Obviously vim mode should modify the Jupyter keymap also. I propose following changes:
  • Down (Jup managed ) --> Ctrl+Down : switch cell
  • Esc ( Jup managed ) --> Esc (Jup managed): not even ADD a modal state but track CM modal state and synchronize Jupyter modal and CM modal
  • 'a' and 'i' (CM vim mod) --> Same thing, escape from vim edit mode AND from Jupyter edit mode

That's it. Feel free to discuss, that's the main purpose of this PR

[Carreau]

Thanks @parleur I'll try to look at that soon !

[Carreau]

High level comments:

Could we have a tick marker on the menu for the currently use keymap ?

[Carreau]

forgotten var that=this ?

[Carreau]

OK, I think that we want to avoid vim shortcut for now, at it seem to be complex. Get the logic right for default/emacs/sublime, and deals with vim later.

[Carreau]

Regardless of that, pretty sweet, and seem to mostly work for me.

[Carreau]

if you set vimMode to null, the update option will remove the key from the config file, which is cleaner I think.

[minrk]

Awesome, people are going to be really happy about this.

[jdfreder]

Sweet! Have you had a chance to try @ivanov 's vimception?

[hack-c]

This looks sweet. @parleur Can you provide some context on what changes were made and where review is most helpful? THanks!!

[jdfreder]

Closed? Did you find an alternative way to implement it?

[Carreau]

Closed? Did you find an alternative way to implement it?

I think @parleur want a bit less attention, and yes, we discussed an alternative for vim keybinding, and had a long conversation on how key handling works in general in the notebook.

[hack-c]

ah great, thanks @Carreau. I'm interested in helping out with "emacs mode" if/when there's an opening.

[Carreau]

The emacs key bindings are not that hard, the issue is with Vim that already have a dual command/edit mode.

We (@parleur and I) think it should be possible to "never" be in jupyter command mode, and have extra keybindings for codemirror that trigger actions at notebook level.

So you can do things like <esc>:run all, or :<esc>:above , or alike.
It needs some refactor, like replacing

if (this.mode === 'edit') {
    return this.edit_shortcuts.call_handler(event);
} else if (this.mode === 'command') {
  return this.command_shortcuts.call_handler(event);
}

by something like:

new_mode = this.mode[this.current_mode].call_handler(event)
this.current_mode = new_mode

To gain some flexibility, and some patching of markdown cell to switch the rendering on focus.

[jdfreder]

^ @Carreau I like that idea

[Carreau]

I think you might need to rebase.

[parleur]

A stupid question: you suggest to rebase on top on current master:HEAD, I am used to merge new HEAD into my dev branch ( I ve read somewhere, it is dangerous to rebase any published commit ). I am wrong? Or is it equivalent ?

[Carreau]

Usually we avoid merging with HEAD.
It is not dangerous to rebase, it can just be a bit more complicated. And anyway locally your commits are still in the reflog, so you cannot lose work.

I can show you how to rebase next Tuesday on Skype if you like.

[Carreau]

Also current commit is parleur@2832c13

So now that it is linked here, whatever you do, we can get it back from GitHub.

[parleur]

A little comment about dynamic Codemirror keymap switching.
CodeMirror have a bug/strange behavior with handlers so that when a handler have been registered before a keymap switch then it is treated after the newly declared codemirror core handler. The solution is to unbind the jupyter handler then switch keymap and rebind it.

[Carreau]

A little comment about dynamic Codemirror keymap switching.
CodeMirror have a bug/strange behavior with handlers so that when a handler have been registered before a keymap switch then it is treated after the newly declared codemirror core handler. The solution is to unbind the jupyter handler then switch keymap and rebind it.

Another solution would be forcing to reload page after switching keymap..

[parleur]

Hmm it would solve the Codemirror bug ... but likely raise other issues. At minimum auto saving before reloading and handle interrupt computation due to keymap switching
Unbind and rebind is proper and simpler (it is needed only about the keydown hander). The cleanest way would be to patch codemirror but it is out of my scope.

[Carreau]

We can likely assume people won't switch keymaps too many time. So I think reloading (with a warning) is acceptable if we want to go this route.

[parleur]

The vim keymap works and going back to default mode. It's quick and dirty but it is an example of pleasant notebook navigation using only the keyboard.

Note that it work using a patched codemirror (already merged) that can be backported onto the current codemirror version used by Jupyter.

[Carreau]

THanks for fixing things upstream. In general CodeMirror is released monthly, so we never have to wait too much between releases.

[Carreau]

related extension: https://github.com/lambdalisue/jupyter-vim-binding

[parleur]

This PR in now close. After many time spent on in it appears that dealing a keymap layer need a proper keyevent handling, and it is not a refacto that can be done under the hood here.

[alok]

I wonder if Neovim's embedding functionality could be used for this, like how ActualVim works, rather than just reimplementing vim-mode like every other project with a vim emulation mode.