[implementations-list] Early implementation of new VIM-like mode

Thu Jul 2 09:38:24 CEST 2009

Marius, thank you for your comments.  I had some of them in my mind when 
I started with vim-mode.

Am Mittwoch, 1. Juli 2009 schrieb Marius Andersen:
> Let's get philosophical for a moment. What is it we "really" want to
> accomplish by writing a new package?
>
>     1. FAITHFUL VIM EMULATION inside Emacs. Key for key, the editing
>        should be as identical to Vim's as possible. "Vim is
> fundamentally correct, but Emacs has some nice extensions like AUCTeX
> and Org-mode."
>
>     2. MODAL INTERFACE to Emacs' powers. Provide a way to define
> modal key bindings, and map them to the word/sentence/paragraph
> functions included with Emacs. "Emacs is Emacs, but modal editing is
> a good idea."

Well I prefer something between #1 and #2.  I would like to have as many 
key-bindings work as in vim (like Jason, I don't want to learn new 
one), but not at any costs.  If some minor aspects don't work as 
expected ... well :)  For example, the position of the cursor after an 
operation is usually different in emacs and vim.

Other things like ex-mode are not so important to me - usually emacs has 
better alternatives.

> [snip]

> What we "really" want, I assert, is not all the specifics of Vim, but
> the general concept of modal editing -- and the ability to combine
> that concept with the rest of Emacs' powers in unlimited ways. (Of
> course, since one of those powers is the ability to faithfully
> emulate vi, the "purists" could get their golden standard simply by
> using this modal interface as a front-end to Viper's emulation
> functions.)

True.  This was one of the things I had in mind when starting with 
vim-mode.  It should be easy to define new modes and keybindings.

> But there are far more interesting ways to employ a modal interface
> than just reimplementing vi. For instance, think of text objects
> again. They aren't just a nifty "Vim trick", but a very reuseable
> idea. Wouldn't it be wicked cool to be able to do
>
>     `cxw' -- transpose words (`M-t' in Emacs)
>     `cxb' -- transpose blocks (`C-M-t' in Emacs)
>     `cxs' -- transpose sentences (`transpose-sentences' in Emacs)
>     `cxp' -- transpose paragraphs (`transpose-paragraphs' in Emacs)
>
> If we could bind `cx' to a command without overwriting the binding
> for `c', then this would be easy. Indeed, this is how Vim's `map'
> command works. But how to implement it in Emacs?

Currently there're two key-concepts in vim-modes: modes and keymaps and 
both should be as independent as possible.

modes are just some functions called on activation and deactivation and 
some keymaps.  In fact, one could easily use real emacs minor-modes for 
this.

keymaps are the real core.  In principle, in the current design it 
should be quite easy to do all those 'cxw' stuff.  You can already 
define 'cxw' without any effect on the 'c' command.  The only required 
functionality is execute some code on each 'intermediate' key (or 
prefix-key in emacs terms) to do something funny.  This is what 
vim-mode does.

The rest of vim-mode is just using this core to bring vim-like-bindings 
to the light.

The point is that emacs' own keymaps are not powerful enough or well 
suited for modal editing (in my opinion).  But it's relatively easy to 
plug another keymap system on top of them.  In fact, the design is 
similar to emacs' own keymaps and minor/major modes.  That's the reason 
why other vim-emulation-packages just use emacs-keymaps and minor 
modes.

> Anyway, the key is orthogonality. The key parser should be orthogonal
> to commands, motions, text objects or whatever creative innovation
> may come along. That way we can add our own, custom modal keys,
> without redefinitions of fixed code, which are difficult to share.

I have to say that currently the core-keymap-system is a little specific 
to vim (e.g. it knows of 'motions', 'commands' and 'argument'), but it 
should not be too difficult to make it more generic (I have some ideas 
in this direction I'll try in the next days).  

And, of course, there're some aspects that are not so easy to do the 
right way for all thinkable model-editing-schemes, like undo/redo or 
repeating.  The current implementation is oriented at vim's.  I have to 
think about making it more generic.

Some last words.  I don't think we should try to build a system that can 
be the base of every thinkable modal-editing-scheme.  Focusing on vim 
seems more important to me, because I think this is what most people 
need and most people are used to.

Just my 2 cents

Frank