RFC: Proposal for new terms for Command mode, Edit mode, etc

[lambdalisue]

Currently we use the terms below

• Jupyter mode
• Vim mode
  • Command mode
  • Insert mode

But the terms above conflict with Jupyter's mode, which use "Command mode" and "Edit mode". So I'm thinking to change the current terms to

• Command mode
• Edit mode (Normal)
• Edit mode (Insert)

To make it clear (corresponding to Jupyter's help page). But I would like to ask you guys to other ideas.

Derived from #53

[traeki]

"Command" mode is a standard pseudonym for vim's "normal" mode (see e.g. http://www.radford.edu/~mhtay/CPSC120/VIM_Editor_Commands.htm, http://stackoverflow.com/questions/13178874/how-do-i-switch-between-command-and-insert-mode-in-vim)

So I think that even though Jupyter uses that term, it is confusing with this extension.

I would call the modes Insert, Normal, and Jupyter-Command, maybe? I know that's cumbersome, but Jupyter has painted us into a semantic corner by having a "command" mode that is totally different from Vim "command-mode". =-/

Whatever the resolution is, I would not simply call either thing "command" mode. It's confusing in either direction.

[lambdalisue]

"Command" mode is a standard pseudonym for vim's "normal" mode Whatever the resolution is, I would not simply call either thing "command" mode. It's confusing in either direction.

Yeah that's y I used "Command mode" for now. But while <F1> leads to Jupyter's help and that help show "Command mode" and "Edit mode", I feel I should use the terms of Jupyter. Or maybe I should find a way to overwrite a help page to re-define terms (I don't know how or can).

[traeki]

Ohh, yeah, I see. If the help categories are unchangeable, that's tricky. If that's not the case, I suggest changing them (i.e. ditching "command" as a mode name). But, if we're stuck with those names, it should be a SUPER EMPHATIC POINT in the Readme that the Jupyter help area calls Jupyter-mode "command" and Vim-mode "edit", and insert mode just doesn't show up at all. (Assuming that's correct.)

[ELLIOTTCABLE]

Jupyter, Normal, Insert.

When a word is ambiguous across two dictionaries, avoid it entirely. (=

(Additionally, this is consistent with the new behaviour where the user spends almost all of their time in ‘Normal’ mode: it is now … normal! Special interactions [<Shift-ESC> for Jupyter mode, i for insert mode] shift out of Normal and into special modes. I feel this terminology is internally consistent. =)

[lambdalisue]

Thanks for feedback. Yeah Jupyter, Normal, Insert sounds nice. But I'm afraid that the categories in help page are labeld "Command mode" and "Edit mode"...

Now I'm feeling that I should overwrite these categories to jupyter-vim-binding's flavor. I'll check the Jupyter's code prob. in this weekend and found whether if it could be or not.

[scientist1642]

I installed the plugin today, thank you for your work! I wanted to give a feedback and glad to see it is opened.

• Shift-s is really inconvenient, double escape to go back to jupyter mode would be perfect. I see this was the case in the earlier version.
• when you enter a new cell (by pressing j or executing the current cell) you get automatically in vim mode again. It would be nice if there is an option which will switch you to jupyter mode instead(and then press i if i want to edit the current cell). Current behavior is somewhat annoying, if you imagine there is a markdown cell below it switches to a source view from rendered one.

[ELLIOTTCABLE]

I'd like to point out that I, personally, like segregating non-vim modes with the <Shift-ESC> keybind. Customizable?

Re: the markdown cells, @scientist1642 makes a good point, though. Is that behaviour you can override? (i.e. retaining “is-in-insert-mode”, and then temporarily leaving insert mode when j'ing down into a Markdown cell, and re-entering insert-mode when j'ing back into a non-rendered cell / code-cell?)

This is a pretty subtle aspect of the functionality, and really needs to be thoroughly thought through. This plugin basically treats an entire Jupyter notebook as a text-file; and vim's mode of control doesn't really mesh well with “opaque blocks of content” that aren't text; especially if they can sometimes become text, like the Markdown cells. Need to consider how that fits into this model most intuitively.

[lambdalisue]

Make a new issue if you would like to talk about different topic please.

[lambdalisue]

Memo: Overriding https://github.com/jupyter/notebook/blob/master/notebook/static/notebook/js/quickhelp.js#L166-L263 will help

[lambdalisue]

Implemented. https://github.com/lambdalisue/jupyter-vim-binding/blob/develop/lib/jupyter/quickhelp.js

Could someone kindly check it?