I'm writing this in the middle of the night, in the hopes I can get back to
sleep ;-)
For many years I have viewed Leo's more-complex-than-vim's environment as a
hindrance to vim-like emulation.
The reverse is true!
Indeed, suppose we specify (using one or more @data nodes), normal-mode
bindings to be used when focus is in the outline pane. We now have a new
design space for key bindings!
For example, j,k,h,l when typed in the outline, would be the equivalent of
the down,up,left and right arrows (when typed in the outline pane). This
has huge implications. But first I had better discuss some recent Ahas
related to vim mode.
1. Vim mode will use all of Leo's key bindings unchanged **except for plain
keys**. So arrow keys, home, end, and all ctrl, shift-ctrl, alt, etc key
bindings will have their same effect in vim-normal mode! In other words,
vim mode gets a "free ride" from Leo's existing key-binding machinery.
Just as a tiny example, the home key will work in the minibuffer as it does
presently.
2. Vim mode should be able to use Leo's existing code for the minibuffer
almost unchanged. Examples:
':' will "drop into" the minibuffer as always. The only difference will be
a more vim-like prompt instead of "full-command:".
's' will prompt for search/replace values using Leo's existing Ctrl-F code,
perhaps slightly modified for vim-mode.
So it would be natural (perhaps using another @data node) to associate J
with Shift-Down-Arrow.
Points 1 and 2 must be understood "in context". That is, it will be
necessary to make (slight!) adjustments to Leo's code when c.vim_mode is
True. This single switch provides flexibility where needed. @mode never
had a chance of providing that flexibility.
Ok. I've discussed the recent (undocumented until now) Aha's about vim.
Let's look at the implications of having per-pane bindings for vim.
1. When focus is in the tree we could use:
- j: same as Down-Arrow, goto-next-visible
-k: same as Up-Arrow, goto-prev-visible
-h: same as Left-Arrow, contract-or-go-left
-l: same as Right-Arrow, expand-and-go-right
- c: clone node
- d: delete node
- h: focus-to-headline
- s: search for headline.
- S: search anywhere.
- m: enter move mode: j,k,h,l move modes.
- J: same as Shift-Down-Arrow, move-outline-left
- K: same as Shift-Up-Arrow, move-outline-up
- H: same as Shift-Left-Arrow, move-outline-right
- L: same as Shift-Right-Arrow, move-outline-lift
Not that we particularly want to type J,K,H,L to move outlines, but it
would be useful as easy-to-see equivalents for the dot command. Or we
could define lower-case keys to move outlines. Suddenly, there are plenty
of key sequences available!
Of course, these are all configurable, so if somebody prefers u,d,l,r for
up, down, left, right that is no problem.
2. [The big Aha] We should allow **any Leo command name** as the "target"
of a vim key sequence.
At present, the vim-emulation code assumes there are vim-related commands
called vim_a, vim_dot, vim_colon, etc. This was a useful start, but it's
clumsy and limited. At present, @data vim-commands have entries of the
form::
vim_<whatever> <keys>
In the new scheme, @data vim-commands will have entries of the form::
leo-command-name <keys>
We will surely will want to define some new vim-related commands, and the
*names* of these new commands will be valid in @data vim-commands settings.
To make this work vc.exec_ will execute a **vim command wrapper** that
calls the actual Leo commands. The wrapper will handle the details common
to all vim commands (supporting dot, for instance). Not sure exactly how
this will work, but I'm pretty sure it will be needed. It should be no big
deal, and the details won't affect the design.
Summary
This is all very exciting:
- New @data settings are a dead easy way of providing per-pane vim-mode
bindings.
- Per-pane bindings in vim mode create much more space for key bindings.
- Allowing any Leo command to be bound to vim normal-mode key sequences is
a breakthrough.
- Using existing bindings for "non-plain" keys in vim normal-mode reduces
the work to be done significantly.
- Similarly, using the minibuffer for vim 's' and vim ":" again reduces the
needed work (and increases the visual feedback).
These new opportunities will create others. But this is enough for now.
Time for sleep.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.
