[implementations-list] Transferring maintainership of Vimpulse (was: Re: viper-in-more-modes)
2007/9/18, Stephen Bach <[email protected]> wrote:
Sure, I'd be willing to put in a little effort. I'm currently running Emacs 22 and a 23 snapshot. Let me know what I can do.
Hi Stephen, Are you interested in taking over maintainership of Vimpulse? But sadly all the pending patches are just sitting in my inbox. Maybe I can forward them all to you? Or, if I don't manage to do that, I can give you my email login and password and you can dig them all up - just do a search through my email for "vimpulse" and maybe "viper-in-more-modes". 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. If you would like that, phone me day or evening at 416-992-3445 (I am on Eastern Standard Time) and I will give you the password. If you are no longer interested, I will seek another new maintainer. I will write an ad seeking a new maintainer inside the Vimpulse source code. BTW, dear list: Anyone interested? Cheers, -Jason
Hi Jason, On Sun, Jan 25, 2009 at 01:52:03PM -0500, Jason Spiro wrote:
Are you interested in taking over maintainership of Vimpulse?
I appreciate being asked, but I'm probably not the best choice to be the formal maintainer. I'd certainly like to see further improvements to vimpulse and a viper-in-more-modes, though. I use them every day. :-) Best, Stephen
On Sun, Jan 25, 2009 at 7:52 PM, Jason Spiro <[email protected]> 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.
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
On Wed, Jan 28, 2009 at 6:14 PM, Stephen Bach <[email protected]> wrote: ...
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.
I agree. It would be very hard to rewrite Viper from scratch. As popular blogger Joel Spolsky wrote: "The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. ... [Architectural] problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. Even fairly major architectural changes can be done without throwing away the code. On the Juno project we spent several months rearchitecting at one point: just moving things around, cleaning them up, creating base classes that made sense, and creating sharp interfaces between the modules. But we did it carefully, with our existing code base, and we didn't introduce new bugs or throw away working code."[1] The books "Working with Legacy Code" by Michael Feathers and "Refactoring" by Martin Fowler, and the SourceMaking website[2], talk about how to refactor. The free PDF ebook "Object-Oriented Reengineering Patterns"[3] also talks about dealing with old code, though I think "Working with Legacy Code" is better. ...
- 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. :-)
Yes; if you go ahead and write it, then when it's ready, I too will try it. Good luck. -Jason ^ [1]. http://www.joelonsoftware.com/articles/fog0000000069.html ^ [2]. http://sourcemaking.com/refactoring ^ [3]. http://www.iam.unibe.ch/~scg/OORP/
On Wed, Jan 28, 2009 at 4:11 PM, Maciej Katafiasz <[email protected]> wrote: ...
I'd like to ask everyone interested in vi-in-emacs: why not go [the vimp] 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?
Once it meets my needs better than Viper plus Vimpulse, then I will switch. Otherwise, I will probably not switch. Sorry :) By the way, I have no private Vimpulse repo. When I modify my local copy of Vimpulse, I upload my changes to the wiki right away. But I haven't touched my local copy of Vimpulse for over a year now; also, there are many unread Vimpulse-related emails which were sent only to me in my inbox. This includes patches. I haven't been reading them or acting on them. I think I have been ignoring them because I am no longer very interested in putting in the effort to maintain Vimpulse. That is why I would like a new maintainer to step up.
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.
Back when I used only Viper, I don't remember finding it buggy at all. So I believe that Vimpulse is buggy, but Viper is not. I haven't investigated though, and I could be wrong. ...
[1] Tentatively called "vimp", although "vimpersonator" is a good candidate as well.
I prefer the name "vimpersonator". The name "vimp" sounds too much like "pimp", which is bad. -- Jason Spiro: software/web developer, packager, trainer, IT consultant. I support Linux, UNIX, Windows, and more. Contact me to discuss your needs. +1 (416) 992-3445 / www.jspiro.com
participants (3)
-
Jason Spiro -
Maciej Katafiasz -
Stephen Bach