Regarding vim emulation, I think it requires all or nothing: modes, commands etc. If Leo can't replicate the vim experience it will just create frustration when muscle memory expectation is disappointed, like playing a piano with keys that don't work.
I think the current 'shell out to vim' is better, since vim users tend to heavily customize their editing environment. One refinement which would be nice is the ability to shell out and be editing the _file_ the current node lives in*, with cursor position maintained in vim, then in Leo upon return. Thanks, Kent *presumably most useful with the sentinel-free @xxx flavors On Tue, Nov 5, 2013 at 12:08 PM, Edward K. Ream <[email protected]> wrote: > While waiting for Leo 4.11 final, I thought I'd post some thoughts about new > kinds of abbreviations. > > 1. Node-creating abbreviations. > > At present, abbreviations expand to text. However, copying a tree also > creates text, namely the xml representation of the tree. You can see this > by doing ctrl-shift-c, then ctrl-v in the body pane. > > It will be straightforward to expand abbreviations to outlines: > > A. Create a new kind of setting, say @abbreviation-tree. Headline contains > abbreviation; children contain the forest of trees to be substituted. > > B. Indicate (somehow) to Leo's key handling that abbreviations created in > this way are to be expanded by pasting the forest *represented* by text, > rather than the text itself. Details omitted. > > 2. Vim-simulation using minibuffer abbreviations. The general idea is pretty > simple: > > A. Make keystrokes in vim's command mode visible in the minibuffer. This > isn't exactly how vim works, but it's close enough for a start. > > B. Add support for numeric arguments and "instant execution" of > abbreviations to Leo's key-handling code, perhaps a version of k.getArg. > > Instead of using @mode nodes, a *set* of abbreviations would define a set of > commands to execute. The handler for minibuffer abbreviations would execute > a command as soon as it becomes the only possible "completion" of the > minibuffer. > > C. Because of numeric arguments and (probably) other considerations, a set > of vim-oriented commands would also be required. In principle, these new > commands could handle all possible vim commands. In practice, some new > design work (on the abbreviations themselves) would be necessary to handle > the much richer environment that Leo provides. > > This kind of framework might be the basis of Leo 5.0. Your comments please. > > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/groups/opt_out. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
