[IPython-dev] Client configuration and vim integration for notebook
Mon Mar 26 17:59:21 CDT 2012
On Tue, Mar 20, 2012 at 5:21 PM, Dale Jung <firstname.lastname@example.org> wrote:
> Were the client side configuration changes from:
> merged into master?
No we haven't moved forward yet with the configuration UI.
> I took a pass at adding the vim bindings into the
> notebook and right now it's only configurable in code.
> The code is here: https://github.com/dalejung/ipython
> The way I approached is to create a set of Notebook level bindings that sync
> with the cell's bindings. I wanted to do away with the control-m shortcuts
> since vim has a non-edit normal mode.
> NormalMode Bindings:
> shift + j: move to next cell
> shift + k: move to prev cell
> shift + y: copy cell
> shift + d: cut cell
> shift + p: paste cell
> shift + a: open cell above
> shift + b: open cell below
> shift + e: execute cell
> shift + f: toggle output on cell
> shift + c: change cell to CodeCell
> shift + m: change cell to MarkdownCell
> i: edit text cell (Note: this toggles the edit window that is in normal
> mode. you must press i again to edit)
> ESC: get out of insert and render textcell
When I think about vim keybindings, I am thinking about how the
code/text editor areas behave when you are editing them. But it
sounds like you are using vim like bindings on the notebook itself -
to manage cells, etc. Is this an accurate description of what you are
Here is a bit more background on the issue of keybindings:
* There are two sets of keybindings in the notebook. The first is
notebook level ones, that manage cell level actions. Most of these
show up when you view the keyboard shortcuts in the help. The second
set of keybindings are active when a cell is being edited. Things
like tab completion are handled by these.
* There can be very subtle interactions between these two sets of key
bindings. The current bindings are finely tuned to deal with these
* All keybindings we use must be free of conflicts on all browsers
(Chrome, FF, Safari) on all operating systems. This means that many
shortcuts you would like to use cannot be used because they are taken.
This is why we went with the ctrl-m prefix for all notebook level
shortcuts as it doesn't conflict.
* The notebook level keyboard shortcuts should not know anything about vim.
* vim/emacs bindings should only take over when a single code/text
cell is being edited.
* Because of a) the subtle interactions between cell and notebook
level bindings and b) the lack of available keyboard shortcuts in
modern browsers, the notebook will not ever have ultra-configurable
> This isn't the full set of shortcuts, but it allows me to work in the
> notebook without touching the mouse or using control-m. If any vim users
> could see how the workflow feels to them. Technically some Notebook
> shortcuts clobber the vim bindings, but I didn't want to create an
> additional Notebook Normal mode. I don't personally use the bindings I
> clashed on but that's only me.
> I haven't used notebook before today so I don't know all the features. I had
> assumed it was only for presentations, but that cell based editing sure is
> nice for exploring :)
> IPython-dev mailing list
Brian E. Granger
Cal Poly State University, San Luis Obispo
email@example.com and firstname.lastname@example.org
More information about the IPython-dev