On Fri, Jan 1, 2010 at 5:52 PM, Stephen Bach <[email protected]> wrote:
Emacs has a very slow development cycle and there are layers of bureaucracy and ego to trudge through, so I think it's unlikely vimpulse or viper-in-more-modes will ever be merged upstream.
If Michael Kifer agrees to it, I can't think of any reason why viper-in-more-modes couldn't get upstream after some minor changes are made (the ones I added to the TODO list). There may be other reasons, but I can't think of any. Can you? Vimpulse still has bugs, and until those are fixed, it definitely won't get upstream. Even after they are fixed, I wonder if it can get upstream.
But I don't think that should be seen as a setback -- I question the benefit of the goal of having these packages included in upstream Emacs in the first place.
1. Speaking broadly, the market for vimpulse users consists of those people migrating from a vi-based editor to Emacs. These people are certain to do their own research before switching editors, as this is a consequential commitment. Therefore most will discover vimpulse -- especially as its userbase and web presence grow -- regardless of whether or not it's in the base install.
2. Patches to Emacs require an explicit transferral of copyright. This bookkeeping is a barrier to contribution, and it's something we wouldn't need to do if we stopped seeking inclusion into Emacs.
The above are all good points.
I think it'd be very unfortunate we'd ever reject a patch for a reason unrelated to its quality, but that's exactly what's being suggested for Alexander's contribution (at least in the short term).
It'd be unfortunate. But maybe it'd be worth it. Then again, maybe not.
3. GNU Emacs enforces the backward policy that packages must not use cl.el Common Lisp extensions at runtime. This kind of restriction is another enemy to development momentum; if it's expedient to Vegard or another developer to leverage a standard library, they should be empowered to do so.
But John J. Foerch said in his email of Wed, Oct 3, 2007 at 11:00 PM at http://my-trac.assembla.com/vimpulse/ticket/2 that there are cl.el macros that override core Emacs functions. Do you still stand by your assertion? Cheers, -Jason