[IPython-dev] Client configuration and vim integration for notebook
Dale Jung
dale at dalejung.com
Mon Mar 26 23:18:00 EDT 2012
>> 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.
More information about the IPython-dev
mailing list