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

[Dale Jung]

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

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. 

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


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

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. 

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.