[implementations-list] Faithful vi/vim emulation vs. modality; etc. (was: Early implementation of new VIM-like mode)

Thu Jul 2 03:58:41 CEST 2009

Marius, your email contained excellent new insights.  Thank you for writing it.

On Wed, Jul 1, 2009 at 9:18 PM, Marius Andersen <rezonatix3 at yahoo.no> 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_mappings

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.