[implementations-list] viper-in-more-modes still needs a maintainer: does anyone volunteer?
Hi all, viper-in-more-modes provides vi-like keymaps for emacs-lisp-mode, lisp-interaction-mode, slime-repl-mode, and lisp-mode. But viper-in-more-modes has some problems. Here's some stuff that should be done, copied from the TODO list in the file: * We shouldn't use the "vimper" function-name prefix anywhere in this file. The word "vimper" is a leftover from back when viper-in-more-modes was part of Vimpulse, and Vimpulse was unreleased and didn't have a good name yet. But viper-in-more-modes is no longer part of Vimpulse. It doesn't require Vimpulse to load. It does provide access to some Vimpulse features like visual mode, but viper-in-more-modes does something different than Vimpulse and so isn't shipped with Vimpulse. So we should pick a new prefix. * Rename viper-in-more-modes to something much shorter. This will not only give viper-in-more-modes a shorter name, but will also instantly provide us with a better prefix. * Clean up the code in general: for example, the error messages shouldn't include exclamation marks. And the grammar and capitalization in the comments should be improved. Also, the boxed comments probably don't have to be in boxes. * Submit it to M-x report-emacs-bug and ask them to please include viper-in-more-modes as part of Viper. viper-in-more-modes has no maintainer. Would someone please take over maintainership? Vegard, you could volunteer. Dear everyone else, you could volunteer too. :) -- Jason Spiro: software/web developer, packager, trainer, IT consultant. I support Linux, UNIX, Windows, and more. Contact me to discuss your needs. +1 (416) 992-3445 / www.jspiro.com
From: [email protected] Date: Mon, 28 Dec 2009 16:29:41 -0500
viper-in-more-modes has no maintainer. Would someone please take over maintainership?
I volunteer. Vegard _________________________________________________________________ Windows 7: Se direkte-TV fra den bærbare PCen. Finn ut mer. http://windows.microsoft.com/windows-7
On Wed, Dec 30, 2009 at 6:06 PM, Vegard Øye <[email protected]> wrote:
From: [email protected] Date: Mon, 28 Dec 2009 16:29:41 -0500
viper-in-more-modes has no maintainer. Would someone please take over maintainership?
I volunteer.
Thank you. As the old maintainer, I accept your volunteership. You're now the new maintainer. When you make your first commit, please make sure to mention in the header that you're the new maintainer. :) 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. viper-in-more-modes is separate from Vimpulse. Neither one requires that the other be installed on the user's hard drive. One is stored on EmacsWiki only; one is stored on Assembla and EmacsWiki. But they both should share implementations-list. When you make a new viper-in-more-modes release, you might want to send an announcement email to the list. Actually, if you make a new Vimpulse release, you might want to send an email to the list too. Cheers, -Jason
From: [email protected] Date: Thu, 31 Dec 2009 19:29:57 -0500
Thank you. As the old maintainer, I accept your volunteership. You're now the new maintainer. When you make your first commit, please make sure to mention in the header that you're the new maintainer. :)
I should probably make an Assembla project for it. Do you know if Assembla allows renaming? Or would it be okay to make a separate folder for it in Vimpulse's repository?
There's only one uncommitted patch.
Where? :) Vegard _________________________________________________________________ Windows 7: Du får hjelp til gjøre mer. Utforsk Windows 7. http://windows.microsoft.com/windows-7
On Fri, Jan 1, 2010 at 9:13 AM, Vegard Øye <[email protected]> wrote:
I should probably make an Assembla project for it. Do you know if Assembla allows renaming?
Renaming projects? I don't know. If they do allow it, I bet it's an operation that their staff have to do manually. Or maybe they don't allow it.
Or would it be okay to make a separate folder for it in Vimpulse's repository?
I think the Vimpulse repo should be for Vim emulation software only, not for other Viper-related stuff.
There's only one uncommitted patch.
Where? :)
http://lists.ourproject.org/pipermail/implementations-list/2009-December/000... By the way, if you do make an Assembla project for viper-in-more-modes, it would be appreciated if you would give me and Alessandro commit rights :) -- Jason Spiro: software/web developer, packager, trainer, IT consultant. I support Linux, UNIX, Windows, and more. Contact me to discuss your needs. +1 (416) 992-3445 / www.jspiro.com
From: [email protected] Date: Fri, 1 Jan 2010 15:35:12 -0500
By the way, if you do make an Assembla project for viper-in-more-modes, it would be appreciated if you would give me and Alessandro commit rights :)
viper-in-more-modes.el now has its own Assembla space at the address below. Did you receive an invitation? http://www.assembla.com/spaces/viper-in-more-modes/ Vegard _________________________________________________________________ Windows 7: Du får hjelp til gjøre mer. Utforsk Windows 7. http://windows.microsoft.com/windows-7
On Thu, Dec 31, 2009 at 07:29:57PM -0500, Jason Spiro wrote:
...
viper-in-more-modes is separate from Vimpulse. Neither one requires that the other be installed on the user's hard drive. One is stored on EmacsWiki only; one is stored on Assembla and EmacsWiki.
Is there a good reason to keep viper-in-more-modes individual from vimpulse? It seems unlikely to me that anyone who uses the former would not also use the latter. Also, the extensions in vimpulse may be things we would want to use in these other modes. I don't think we need to integrate the two packages, but I don't think it's worth enforcing a separation. P.S. Jason: my first attempt to send this message was rejected because the mailing list service didn't recognize the content type of my PGP signature. If it's configurable, you may want to relax this constraint.
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.
2010/1/1 Stephen Bach <[email protected]>:
On Thu, Dec 31, 2009 at 07:29:57PM -0500, Jason Spiro 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. But I don't think (...)
IMHO Stephen has made an excellent point here. And I can understand the position of the Emacs team too: they have a "core" system, and they're trying to keep it as thin and simple as they can. Of course there's a lot of history, politics and... (folklore, maybe?) in the list of packages distributed with Emacs -- were not for that, I bet they'd already dumped off half of it. Don't you think there'd be more sense in promoting some kind of comprehensive, widely available repository of software for Emacs, like the Emacs Wiki? Cheers, -- José A. Romero L. escherdragon at gmail.com "We who cut mere stones must always be envisioning cathedrals." (Quarry worker's creed)
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
On Sat, Jan 2, 2010 at 10:40 PM, Jason Spiro <[email protected]> wrote: [snip]
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?
Followup to that last paragraph above: note that as of Vegard's change http://my-trac.assembla.com/vimpulse/changeset/38/trunk Vimpulse now doesn't use cl.el at all. His change does not invalidate your assertion though.
On Sat, Jan 02, 2010 at 10:40:10PM -0500, Jason Spiro wrote:
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?
Yes. cl.el's version of push subsumes GNU Emacs' standard push - it's not dangerous. Almost anyone who uses Emacs extensively will load cl.el as part of their configuration. XEmacs loads it by default.
participants (4)
-
Jason Spiro -
José A. Romero L. -
Stephen Bach -
Vegard Øye