[implementations-list] viper-in-more-modes still needs a maintainer: does anyone volunteer?
jasonspiro3 at gmail.com
Sun Jan 3 04:40:10 CET 2010
On Fri, Jan 1, 2010 at 5:52 PM, Stephen Bach <sjbach at sjbach.com> 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
> 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
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
More information about the implementations-list