[implementations-list] viper-in-more-modes still needs a maintainer: does anyone volunteer?

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