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.