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

[Brian Granger]

On Mon, Mar 26, 2012 at 8:18 PM, Dale Jung <dale at dalejung.com> wrote:
>
>>> 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.
>
> That's how I originally approached it. I think having a notebook-level normal mode is good for emacs/default since going into cell mode drops you directly into edit.

OK.

> I found the 3 levels of vim confusing. To be honest, I don't know if that's because of the three levels specifically or my first pass at it. The main issue was that going from notebook-normal mode to cell-edit mode took two shortcuts. You'd have to press 'i' twice to get into cell-edit, and esc twice to get back into notebook-normal. Potentially, this could be fixed by going directly into cell-edit form notebook-normal. Or maybe two types of cell-mode entry shortcuts. I don't know. I abandoned it fairly quickly.

I can imagine it would be confusing, I can't handle the two modes of vim.

> God, I just realized how confusing it is trying to articulate vim modes. We vimmers must be crazy.

No comment ;-)

>
>>
>>>
>>>> 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.
>>>
>
> I think this is going to have to be easily configurable. Since the shortcut logic is really just a giant switch/ifelse statement, people will end up editing the source if it's not configurable. Especially as people start consistently using notebook in their workflow. Personally, I use a kinesis keyboard and don't have control key mapped to a convenient button since I'm on a mac. It just doesn't feel naturally to use it. So I've mapped commands to meta+key.

It is not just a giant switch statement though.  Because of the way
events propagate in the browser, multiple DOM elements can end up
handling a single event.  When a cell div is in focus, we have to do
additional logic to deal with the fact that both the notebook and cell
are handling the same events.  It took us a very long time of chasing
down extremely subtle bugs to nail this logic.  If we allow people to
configure their keyboard shortcuts in arbitrary ways, that logic won't
be right and the notebook will break.

Personally, I think it is more important that the notebook has a
single, extremely good set of keyboard shortcuts than it is to have
configurable keyboard shortcuts.  We do need to improve what we have
and I think the improvements I describe above would get us closer.  I
will admit that this discussion is getting into a philosophical design
issue that I feel strong about.  I don't think good design requires a
high degree of configurability.  In fact I would say that much of the
time, configurability is used to cover up poor design and an inability
of developers to get it really right.

In that light I don't think our current keyboard bindings are that
great.  They definitely need improvement and we are committed to doing
that.

> I know I know. A mac kinesis-using vimmer, it's pretty obviously I'm particular about keystrokes.

>>>> * 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.
>
> That's where I disagree. If I'm using the notebook then I'm using the notebook and not the browser. In fact, I run the notebook in safari where my primary browser is chrome. I have keybindings that conflict with browser bindings. I understand that ipython can't assume it's okay to take over a shortcut, but I should be able to make that choice.
>
> I wonder if making a webkit embedded console app is feasible. That's pretty much how I run my safari notebook, no location/toolbars.

I would imagine it would be, but we haven't thought about that yet.

> btw, I love ipthon notebook but it's weird that I do so much dev work from within a web browser. Especially since I've always prided myself on using terminal/vim and eschewing those fancy GUI text editors. Craziness.

Glad you like it.  I consider it a huge milestone for us that we can
get hardcore vim/emacs users to use the notebook.  It is a tough crowd
to please and I know we have a ways to go...

Cheers,

Brian

>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com