Marius, your email contained excellent new insights. Thank you for writing it. On Wed, Jul 1, 2009 at 9:18 PM, Marius Andersen <[email protected]> wrote:

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

I personally would prefer #1, faithful Vim emulation, so that I can learn one set of keys in my muscle memory and use them in both Vim (the editor I have set the Vimperator addon for Firefox to use as my external editor) and Emacs (which I use for IRC and other uses). #2 would be an ok second-best choice, but I would be annoyed at having to learn a new set of keys, and I would be annoyed that the modal editing keys in Vim and Emacs would be slightly different.

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?

I would prefer to have a translator, even though it'd be a lot more work to write.

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.

But surely it can be prettier than how Viper is now. It sounds to me like viper contains a lot of kludges.

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

Why? Because Viper contains so much built-in knowledge about how Vi works, just like autoconf contains so much built-in information about how various Unix variants work? There always is the option of rewriting from scratch. Though the opinion I've read (Joel Spolsky's) says don't do it, it takes too long and you will lose the built-in knowledge and bug fixes.

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

It sounds like Viper wasn't written perfectly.

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)

Some people have already come up with Vim mappings you can map so you can swap words and paragraphs: http://vim.wikia.com/wiki/Swapping_characters,_words_and_lines#Normal-mode_m... If it would be useful to have such functionality in Vimpulse, then why don't we get it added to Vim first, then make a clone of that feature for Vimpulse?

[snip]

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.

What if someone (not me) were to refactor Viper or one of the other vi emulators for emacs listed at http://texteditors.org/cgi-bin/wiki.pl?ViFamily bit-by-bit to make it easier to customize? They could start by rewriting the key parser part. Then they could do other things such as refactor out globals. I think a good goal would be to always keep Viper fully working after every stage of modification -- and every stage should be fifteen hours of work or less.

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.

You mean that we would get more total functionality available per hour of modal mode developers' time? Yes, I agree.