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

Brian Granger ellisonbg@gmail....
Mon Mar 26 21:22:24 CDT 2012


Dale,

On Mon, Mar 26, 2012 at 5:56 PM, Dale Jung <dale@dalejung.com> wrote:
> Replying from iPhone. Will reply more in detail.

You did pretty good in replying on your iPhone :)

> 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 this actually does bring to mind some plans that we have for the
notebook.  Currently, when a cell is selected, the text area is active
and typing will affect the text area.  IOW, a cell can't be selected
without being in "edit" mode.  We plan on relaxing that so when a cell
is initially selected, it is not in edit mode.  In that mode, we will
have new keyboard bindings that are notebook level and will probably
be similar to the type of thing you are doing.  As you point out, the
nice thing about this approach is that you can use very simple
keyboard shortcuts (like j,k,i, etc.).  When a cell is selected, you
can enter edit mode and then the text area of that cell will behave in
the usual manner with emacs or vim bindings.

But in my mind, the vim/emacs stuff should not bleed out into the
non-edit notebook mode.

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

I don't think these two things should be done in the same mode.  The
reason is that it means the notebook level command have to be built
around the existing vim infrastructure.  Using vim command for moving
around the text area should be a completely separate mode from
notebook level commands.  Here is a sketch of what I am thinking:

For emacs bindings there would be two modes:

* Notebook level command mode that allows you to perform cell/notebook
level actions.
* Text edit mode for an editing a single cell's text using emacs style bindings.

For vim bindings there would be three modes:

* Notebook level command mode that allows you to perform cell/notebook
level actions.  The keyboard shortcuts in this mode would match those
in the emacs scenario exactly.  That is the keybindings have nothing
to do with emacs or vim.
* vim normal mode for a single selected cell.
* vim insert mode for a sigle selected cell.

This probably looks confusing, but vim is confusing ;-)

My goal in all of this is to have uniform notebook level keyboard
shortcuts that apply regardless of which keybindings are used to edit
single text areas.

>
>> 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. :(.

With the approach I outline above, we should improve the code mirror
vim bindings themselves.

Cheers,

Brian

>>
>> 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
> _______________________________________________
> 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


More information about the IPython-dev mailing list