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