[implementations-list] Transferring maintainership of Vimpulse (was: Re: viper-in-more-modes)

Wed Jan 28 22:11:27 CET 2009

On Sun, Jan 25, 2009 at 7:52 PM, Jason Spiro <jasonspiro3 at gmail.com> wrote:
> An even more important problem:  I think Vimpulse should be part of
> Emacs, so we should start getting copyright assignments now, or get
> all the code of Vimpulse released to the public domain by its authors.

That's not directly related to the topic, but IMHO there's one very
significant problem with vimpulse: it's based on viper, whose code is
(IMHO) ugly as sin and generally impossible to follow and extend in
any meaningful way. I tried to fix certain annoyances and port some
vim features over, but I decided it'd be much easier to simply write a
proper framework for a vim clone than trying to fix the ugly mess of
viper. As much as I understand the need to keep working code and fight
the NIH tendencies, I don't think that code where even the simplest
commands are hardcoded and spread across at least 4 levels of
partially mutually-recursive functions that communicate using global
dynamic state is something to preserve. Not  to mention it's buggy
like all hell in even the most basic things (for a small demo, try
typing ofoo.*bar<ESC>bcwbaz in viper and compare the results with vim,
nvi, or elvis. Now try 3o<ESC> and weep). It's simply not worth the
time it takes to learn and understand the huge mess to make even the
simplest change.

For the reasons above, I started writing my own vim-in-emacs
package[1], with the goal of having it clean, modular, properly
macroised with commands defined declaratively as much as possible,
with support for vi-like :map at least feasible, if not immediately
implemented, etc. So far I have all of 2 commands and 4 motions and
got to the exciting phase of figuring out how to implement the
highly-regular-and-not-arbitrary-at-all-no-siree semantics of linewise
vs. characterwise motions :), so it's nowhere near being usable, but
it's already slightly better than viper in motions it supports. Thus,
I'd like to ask everyone interested in vi-in-emacs: why not go that
way instead of trying to fix viper? If I stopped slacking off,
converted my morning commuting hours to hacking on vimp instead of
watching anime, made a proper, public repo (another big problem with
vimpulse), would anyone be interested? I seriously want to switch to
the vi(m) editing model, and I seriously don't want to leave emacs,
and I seriously think viper is too buggy to be useful for anything.
Does anyone else feel that way enough to join?

Cheers,
Maciej

[1] Tentatively called "vimp", although "vimpersonator" is a good
candidate as well.