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

[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."

There is a myriad of small differences between Vim and Emacs. For example, Vim's regular expressions are slighty different from Emacs'. Should we write a translator from one to the other, or do we simply bind `/' to `isearch-forward' and encourage the user to adjust? Or, when jumping back to previous locations in the buffer, Vim's `C-o' works slighty different than Emacs' `C-u C-SPC'. Do we re-implement this functionality, or should we stick with Emacs' function?

The further we go down this road, the more obvious it becomes that a package that views another editor as the standard can never be very pretty. Viper is an emulator, and it takes tons and tons of replacement code to overrule all the Emacs specifics. It's a self-reinforcing strategy, too: once you've rewritten one function, you typically also have to rewrite the larger system it was part of, and so on.

In short, if #1 is the goal, stay with Viper.

However, and this is where we get philosophical again, there's something odd about the current state of things. Isn't the very point of using Emacs the power to extend and program it to one's liking? And yet, as we have seen, extending Viper turned out to be a "hackish" and unwieldy process. Worse still, there are few general solutions: e.g., adding text objects by redefining a function means the same function must be redefined again when adding something else. (For the record, this hack was my suggestion.)

As someone said, the only way to improve your work or life is by understanding and examining why you do what you do.

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.)

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?

Well, Frank Fischer is definitely onto something. Myself, I imagine some list of modal bindings -- wherein `c' maps to `change-command', `cx' to `transpose-object-command', and so on. Then, `change-command' calls the function `modal-read' to read input from the keyboard:

    (modal-read expectation)

Here, `expectation' is what the calling command expects to get. `change-command' may call it like (modal-read motion), where `motion' somehow defines the keys that make up a text motion, like `3w'. Now, if the expectation is not met -- `x' is not a motion -- then `modal-read' will look up `cx' in the modal bindings list, and find `transpose-object-command'. Control will then be passed on to `transpose-object-command', which may read from the keyboard with (modal-read text-object).

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've probably said more than enough for now. But please, give some thought to what we really "want" from a total rewrite. With #1, Vim is the limit. With #2, Emacs is.


      _________________________________________________________
Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og
notisblokk. http://no.mail.yahoo.com