eliminate Jupyter's command mode

[wilzbach]

tl;dr: There is only the j and k feature that we would loose by eliminating Jupyter's command mode.

For me it just feels wrong that we have three different modes: (1) Jupyter command's mode, (2) CodeMirror's/Vim' command mode and (3) CodeMirror's/Vim' edit mode (let's leave the visual mode out).

In my humble opinion we don't need Jupyter's command mode and could stay in CodeMirror's command mode the entire time - I have looked at all existing command mode mappings and here is my opinion/result:

Should work fine

        'ctrl-c': 'jupyter-notebook:interrupt-kernel',
        'ctrl-j': 'jupyter-notebook:select-next-cell',
        'ctrl-k': 'jupyter-notebook:select-previous-cell',
        'shift-j': 'jupyter-notebook:extend-marked-cells-below',
        'shift-k': 'jupyter-notebook:extend-marked-cells-above',
        'shift-m': 'jupyter-notebook:merge-cells',
        'ctrl-1': 'jupyter-notebook:change-cell-to-code',
        'ctrl-2': 'jupyter-notebook:change-cell-to-markdown',
        'ctrl-3': 'jupyter-notebook:change-cell-to-raw',
        'shift-h': 'jupyter-notebook:show-keyboard-shortcuts',
        'shift-l': 'jupyter-notebook:toggle-cell-line-numbers',
        'shift-v': 'jupyter-notebook:toggle-cell-output-collapsed',
        'shift-s': 'jupyter-notebook:toggle-cell-output-scrolled',
        'ctrl-s': 'jupyter-notebook:save-notebook',
        'shift-g': 'vim-binding:select-last-cell',
        'ctrl-u': 'jupyter-notebook:scroll-notebook-up',
        'ctrl-d': 'jupyter-notebook:scroll-notebook-down',
        'alt-enter': 'jupyter-notebook:run-cell-and-insert-below',
        'ctrl-enter': 'jupyter-notebook:run-cell',
        'shift-enter': 'jupyter-notebook:run-cell-and-select-next',
        'z,z': 'jupyter-notebook:scroll-cell-center',
        'z,t': 'jupyter-notebook:scroll-cell-top',
        '0,0': 'jupyter-notebook:confirm-restart-kernel',

Easily resolved

        'shift-o': 'jupyter-notebook:insert-cell-above',
        'o': 'jupyter-notebook:insert-cell-below',

-> only use shift-o

        'enter': 'jupyter-notebook:enter-edit-mode',
        'i': 'jupyter-notebook:enter-edit-mode',

Edit mode would only be vim's edit mode.

        'esc': 'jupyter-notebook:close-pager',
        'q': 'jupyter-notebook:close-pager',

This would just leave vim's insert mode.

        'y,y': 'jupyter-notebook:copy-cell',
        'd,d': 'jupyter-notebook:cut-cell',
        'shift-p': 'jupyter-notebook:paste-cell-above',
        'p': 'jupyter-notebook:paste-cell-below',

I propose shift-y, shift-d, shift-p and ctrl-shift-p. This could also be different, but should be consistent with the other commands, so that shift-letter is always below and ctrl-shift-letter is above (or ctrl-letter is below) - anyways I hope my point is clear ;-)

        'g,g': 'vim-binding:select-first-cell',
        'u': 'jupyter-notebook:undo-cell-deletion',

I propose shift-g and shift-u.

        '1': 'jupyter-notebook:change-cell-to-heading-1',
        '2': 'jupyter-notebook:change-cell-to-heading-2',
        '3': 'jupyter-notebook:change-cell-to-heading-3',
        '4': 'jupyter-notebook:change-cell-to-heading-4',
        '5': 'jupyter-notebook:change-cell-to-heading-5',
        '6': 'jupyter-notebook:change-cell-to-heading-6',

I am not sure how useful those commands really are, so how about ctrl-h,1, ctrl-h,2 ... ?
(ctrl-h is usually mapped to the history in browsers, but I would safely assume that one doesn't need to access it during vim mode)

Some work/action required

        'j': 'vim-binding:scroll-down',
        'k': 'vim-binding:scroll-up',

I would imagine to patch those commands so once j hits the last line of a cell, it will automatically jump to the first line of the next - et vice versa for k.
I will open a separate issue for that ;-)

[wilzbach]

As it seems to be trickier than thought to hijack the evalInput in CodeMirror, we could also use the arrow keys or shift-j for scrolling?

[lambdalisue]

Hum... This would change the concept of jupyter-vim-binding so I should be really careful to decide.
My current questions are

1. Some keymaps are conflicted with Vim's mapping (e.g. Shift-g, Ctrl-u, etc.) and I don't really think we should change the behaviour of Vim mode
2. Staying always in edit mode have a potential to cause some problem on other plugins

So current my feeling for this proposal is a bit negative. Let me know more positive points.

[wilzbach]

Hum... This would change the concept of jupyter-vim-binding so I should be really careful to decide.
My current questions are

No worries - this is just a general idea that I had ;-)

Some keymaps are conflicted with Vim's mapping (e.g. Shift-g, Ctrl-u, etc.) and I don't really think we should change the behaviour of Vim mode

Hmm we could always remap them or use another leader key?

Staying always in edit mode have a potential to cause some problem on other plugins

How about making this an opt-in option until we have figured out whether this would conflict with other plugins?

Let me know more positive points.

Well the main advantage of working purely in a "VimMode" are (1) is it's less confusing in which mode one currently is in (2) it's faster because one doesn't need to switch from command to edit mode all the time. I was annoyed a lot by needing to switch back to the command mode for daily actions like running a cell, toggling the output or deleting the cell.

If you don't like this so much, I can also add this to the wiki and we wait on the feedback from other users ;-)

[lambdalisue]

Well the main advantage of working purely in a "VimMode" are (1) is it's less confusing in which mode one currently is in (2) it's faster because one doesn't need to switch from command to edit mode all the time. I was annoyed a lot by needing to switch back to the command mode for daily actions like running a cell, toggling the output or deleting the cell.

Make sense. But give me a time...

If you don't like this so much, I can also add this to the wiki and we wait on the feedback from other users ;-)

I'm not really sure if I don't like this. I'll try when I have enough time to implement this feature.
Well I think a wiki is not a place for discussion so I think this issue would stand for getting feedbacks from other users :-)

[petergthatsme]

I for one fully agree with the greenify and think that having a single "vim mode" would simplify the navigation around the worksheet substantially. As a side note, this is how the vim mode editing in sage notebooks works.

[lambdalisue]

Thanks for the feedback :-)

As a side note, this is how the vim mode editing in sage notebooks works.

Could you show me a working example? I would like to try.

[petergthatsme]

More specifically I meant sage-math-cloud notebooks (https://cloud.sagemath.com/) - although recently I think the server portion has been fully open sourced so one can probably run the whole thing locally. To see it in action you might have to create an account with them (which you may or may not want to do), open up a new sage notebook, and in settings set editing to vim.

By default, in those notebooks, pressing 'j' when at bottom of a cell will automatically move you to the next cell, while keeping you in vim's command mode.... there is no going back after using it for a while ;)

[ELLIOTTCABLE]

Yeah, 👍 here. The multiple nested modes are suuuuper confusing: there's non-edit mode, then edit-mode-but-really-in-vim-command-mode, and then true edit-mode-vim-edit-mode …

Navigation still stumps me constantly; I'd realllllly prefer to see what @petergthatsme describes: j immediately moves to the next opened-for-editing cell (although I'd prefer if it would skip plain-text cells that are evaluated; I don't want to j my way through all of the text between the code cells, you know? Maybe a special key-bind to open the cell below for editing, instead …)

[yjk21]

I would love to see this separation suggested by @greenify.
Although vimception is a genius name for the original project, it's something I struggle with a lot.
Any updates on this?

Also, I tend to hit ESC sometimes several times. If there is no overlap of shortcuts, would it be possible to stay in vim mode in the current cell?

Thanks!

[lambdalisue]

Also, I tend to hit ESC sometimes several times. If there is no overlap of shortcuts, would it be possible to stay in vim mode in the current cell?

Actually me too. But currently there is no chance to stay in vim mode.

---

This suggested implementation requires big change so need time. But currently I don't have enough time to focus on this large implementation.
If someone designed and send me PR, I would love to review the code ;-)

[lambdalisue]

As like you guys, I'm heavy user of jupyter-vim-binding and I also feel annoying for three individual modes (Jupyter Command | Vim Command | Vim Insert) so sending me a PR is really welcome :-)

[petergthatsme]

i'm probably missing something as haven't played with the code enough... but wouldn't disabling leaving the vim mode via ESC in leaveInsertOrNormalMode() along with the update from [(https://github.com//pull/31)] but a good first step to basically not need the "jupyter command" mode for normal operations?

[lambdalisue]

Hum... what do you guys think about operations like:

=======Jupyter===========
        | ^
(Enter) | | (Shift+Esc)
        v |
========Vim (Command)====
        | ^
    (i) | | (Esc)
        v |
========Vim (Insert)=====

I'm not sure about mouse operation yet.
I'm thinking that if we could hit <Esc> twice or more to make sure that the current mode is in Command mode, it's enough for starting-point (what @greenify said requires careful review though).

@petergthatsme @greenify @ELLIOTTCABLE @yjk21

[petergthatsme]

IMHO the long term goal should be to get rid of the Jupyter mode altogether... but at as a starting point your proposal would work.

[yjk21]

The Shift-ESC proposal sounds very much worth trying.
Thanks

[lambdalisue]

I knew I'm a person who try too hard to make a new one lol.
I thought I would just switch <Esc> to <Shift-Esc> but suddenly I noticed that I did everything suggested in here ;-)

See #51 and please give me feedback to improve the new version

ping @petergthatsme @greenify @ELLIOTTCABLE @yjk21

[petergthatsme]

great - thanks for doing this... i will play with the new code base shortly, once i get a little time