[RFC] whitespace.el

David Kastrup dak at gnu.org
Fri Apr 27 04:54:36 EDT 2007


Didier Verna <didier at xemacs.org> writes:

> I have some extensions to whitespace.el that I'd like to commit, but
> I would like to know the status wrt GNU Emacs:
>
> - No news from the apparent maintainer: Rajesh Vaidheeswarran <rv at gnu.org>
> - Last incorporation in packages seems to be 2 years old:
>   $Id: whitespace.el,v 1.3 2005/03/25 17:09:08 aidan Exp $
> - But it says: Synched up with: FSF 21.3.
> - Advertised URL is inoperative: http://www.dsmit.com/lisp/
>
>
> So, should I just commit my changes, propose them to the GNU Emacs
> team, or what ?

I'll try covering the GNU Emacs angle.  This is made considerably
easier since you have a copyright assignment on file, so at least from
the licensing situation, you need not differentiate your
contributions.

If your changes would cleanly apply as patch to the version in GNU
Emacs, you can (assuming you don't have developer access yourself)
post the patch (in context diff format, not unified diff) to the
developer list, explain the changes (and to what degree you tested
them on Emacs) and write "could somebody apply this?".  That would
usually work.  You could add your changes yourself to XEmacs then, or
wait until the next synchronization.  Since you very likely prefer to
see them sooner rather than in a few years, you'd likely want to apply
them yourself.  They would probably not complicate a later
synchronization.

If the situation is such that you can't figure out whether your stuff
would still apply to the GNU Emacs version or work there, the
situation would be somewhat different.  You'd probably have to propose
the changes, argue for them and post the patch you did for the XEmacs
version (the patch will contain context taken from XEmacs, but the
_content_ of the _changes_ that are going to end up in Emacs will have
originated just with you).

There is also the possibility of posting just code fragments and
explanations.  In any case, the more straightforward the work for the
other developers is, the more likely is an unproblematic inclusion.

You might want to wait until the Emacs 22 release excitement is over
(the release should be any year now: I actually just blew my cork at
RMS putting in another prerelease-requiring change without which it
might have happened tomorrow), though.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum



More information about the XEmacs-Beta mailing list