[IPython-dev] Client configuration and vim integration for notebook
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 <email@example.com> wrote:
> On Tue, Mar 20, 2012 at 5:21 PM, Dale Jung <firstname.lastname@example.org> wrote:
>> Were the client side configuration changes from:
>> 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
>> 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
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
> * 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. :(.
>> 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
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> email@example.com and firstname.lastname@example.org
> IPython-dev mailing list
More information about the IPython-dev