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

[Stephen Bach]

On Thu, Dec 31, 2009 at 07:29:57PM -0500, Jason Spiro wrote:
> ...
>
> There's only one uncommitted patch.  It's at least a year old.  I
> forwarded it to implementations-list a month or two ago; IIRC it's
> from someone named Alexander with a Russian-sounding surname.  I
> decided to wait until he agrees to possible future copyright
> assignment before merging it.  I recommend you continue to wait.  Or
> you can merge it now.  But if we can't contact Alexander at
> upstreaming time, then we'll have to remove his work from Emacs.  So
> maybe it's better to try now to find a working way to contact him, and
> maybe to warn that you don't plan to merge his work unless he provides
> alternate contact info for possible future upstreaming.

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

  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.