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

[Stephen Bach]

Hi Maciej,

On Wed, Jan 28, 2009 at 10:11:27PM +0100, Maciej Katafiasz wrote:
> 
> 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.

I agree there are problems with viper, but I'm not positive replacing it
wholesale is the best approach.  In my experience, the more ambitious
the project, the less likely it is to reach any milestone of usefulness.
Viper is 13000+ lines of seasoned code, and it mostly works in its goal
of pure-vi emulation.

> 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?

The overriding problem with vi/vim emulation in Emacs is integrating
modal editing into a multi-use editor which doesn't want it.  Do you
think you can do this better than viper has done (i.e. not well)?  If
so, excellent!  But I'd look into this carefully before starting over
because of minor -- though important -- emulation behaviour
inconsistencies, which could be enumerated and fixed in the existing
package.

This said, a few other points to make:

- I suggest only implementing the editing model, and not the ex command
  line as viper has done.  I think this ugly piece of vi should be
  ended.  Use the execute-extended-command interface instead.
- Setup the public repo early, even if you're the only one committing to
  it.
- You seem to know what you're doing, so good luck.  I'll follow your
  work, and when vimp / vimpersonator is ready, I'll try it. :-)

Best,
Stephen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : /pipermail/implementations-list/attachments/20090128/13d7e293/attachment.pgp