[IPython-dev] Client configuration and vim integration for notebook

Dale Jung dale@dalejung....
Mon Mar 26 19:56:14 CDT 2012

Replying from iPhone. Will reply more in detail. 

On Mar 26, 2012, at 6:59 PM, Brian Granger <ellisonbg@gmail.com> wrote:

> Dale,
> On Tue, Mar 20, 2012 at 5:21 PM, Dale Jung <dale@dalejung.com> wrote:
>> Were the client side configuration changes from:
>> http://mail.scipy.org/pipermail/ipython-dev/2012-January/008665.html
>> 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
>> TextCell:
>> 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
> doing?

Kind of. I'm syncing the vim cell binding with the notebook. When the cell is in normal mode, I am making use of additional notebook level bindings. 

So once you exit out of editing a cell (esc) you can use vim commands to move around the text area and do notebook level commands.  

> 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
> issues.
> * 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.

Since text isn't editable in normal mode, this allows us to make use of bindings that won't conflict. For example shift a makes a cell above. 

> * 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
> keyboard shortcuts.

I've been working purely with the vim branch and making edits as things come up. I have to say the biggest hurdle is the fact that the code mirror vim bindings are currently lackluster. No visual mode or block selecting. :(. 

> Cheers,
> Brian
>> 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
>> IPython-dev@scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> -- 
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger@calpoly.edu and ellisonbg@gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

More information about the IPython-dev mailing list