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(a)gnu.org&gt;
- 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
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

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.
[...]

Thanks for the feedback. I've just checked out CVS GNU Emacs, and guess
what ? our two whitespace.el are already somewhat divergent :-( Not sure
if I have the energy (or even the time) to sync again, which would be
the best thing to do before applying my own changes.
Point is, I already have one bad experience in this matter: I completely
rewrote rect.el back 1999, for both GNU Emacs and XEmacs (BTW, I'm still
listed as the official maintainer for this library). They agreed to
incorporate my version and some time after that, I discovered numerous
changes which they did not bother to report back to me. I'm not upset
anymore ;-), but I really don't feel like speding time and energy on
anything new in these lines unless I have some control on things.
Anyway, since 1/ now is not the time for them, and 2/ we're diverging
already, I'll probably apply my changes in the XEmacs package (and let
people play with it), and defer the "sync decision" to some time later...

David Kastrup <dak(a)gnu.org&gt; wrote:
Point is, I already have one bad experience in this matter: I
completely rewrote rect.el back 1999, for both GNU Emacs and XEmacs
(BTW, I'm still listed as the official maintainer for this
library). They agreed to incorporate my version and some time after
that, I discovered numerous changes which they did not bother to
report back to me. I'm not upset anymore ;-), but I really don't
feel like speding time and energy on anything new in these lines
unless I have some control on things.

Putting yourself in as the maintainer at the top of the file
considerably helps usually.
But you won't have "control" in any manner: that is pretty much the
point of the copyright assignment: passing the control.
I don't think that it is a good idea to suggest in a multiperson free
software project that every contributor retains individual control.
While there are projects (like the Linux kernel) where this is
factually the case, having every contributor able to throw a monkey
wrench into further development is calling for trouble in the long
run. Alienation _does_ happen in personal and professional
relationships.

Anyway, since 1/ now is not the time for them, and 2/ we're
diverging already, I'll probably apply my changes in the XEmacs
package (and let people play with it), and defer the "sync decision"
to some time later...

Hopefully not forever. But then that's the same worry I have about
Emacs 22.

Didier Verna <didier(a)xemacs.org&gt; writes:
> David Kastrup <dak(a)gnu.org&gt; wrote:
>
> Point is, I already have one bad experience in this matter: I
> completely rewrote rect.el back 1999, for both GNU Emacs and XEmacs
> (BTW, I'm still listed as the official maintainer for this library).
> They agreed to incorporate my version and some time after that, I
> discovered numerous changes which they did not bother to report back
> to me. I'm not upset anymore ;-), but I really don't feel like
> speding time and energy on anything new in these lines unless I have
> some control on things.
Putting yourself in as the maintainer at the top of the file
considerably helps usually.

But you won't have "control" in any manner: that is
pretty much the
point of the copyright assignment: passing the control. I don't think
that it is a good idea to suggest in a multiperson free software
project that every contributor retains individual control.

I agree, but the problem here is that we're talking about *two*
multiperson free software projects. I can't seem to have people modiying
rect.el in GNU Emacs report the changes back to me, and that's already
annoying. Then, I could probably track these changes myself and try to
merge them on a regular basis with those in XEmacs, but still, I would
have to "propose" the merges back to GNU Emacs each time, with people
doing stuff under my feet, as it happened before. Add questions of
different coding styles that would never be resolved, and so on... and
you'll understand my wish for minimal "control" (starting with commit
access for instance[1]).
Footnotes:
[1] Admitedly, I never tried to ask for it, so I don't know what the
answer would be.
--
Read the Jazz Blog !! http://jazzblog.didierverna.com
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup <dak(a)gnu.org&gt; wrote:
you'll understand my wish for minimal "control" (starting with
commit access for instance[1]).
Footnotes:
[1] Admitedly, I never tried to ask for it, so I don't know what the
answer would be.

You are an author of some files in Emacs and have a copyright
assignment for it on file. I have no idea why you should _not_ get
CVS access for it on Savannah unless you manage to ask for it in a
manner rubbing people in the wrong way very badly.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

So, should I just commit my changes, propose them to the GNU Emacs
team,
or what ?

IMO, if they're non-controversial, commit, then propose. It'd be nice
if you'd accept ownership of the library at the same time. :-) (If you
do, you might want to get in touch with the python-mode maintainers
Barry Warsaw (barry =at= python org) and/or Skip Montanaro (skip =at=
pobox com). whitespace cleanup has been an issue on Python lists the
last couple of days, and they might be interested.
Thing about talking to GNU is that GNU Emacs is currently about to
release (currently schedule seems to be to do a pretest early next
week, and release the following Monday), and they're not going to be
any fun to talk to until they do. (rms is still authorizing commits
for anything that looks vaguely like a bug, so the schedule is kind of
uncertain.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> ... whitespace cleanup has been an issue on Python lists the
Stephen> last couple of days, and they might be interested.
Just an FYI (haven't posted this to python-dev yet), my problems with
dangling whitespace are caused by hitting RET or LF (py-newline-and-indent)
which indents according to the current environment, then moving away from
that indentation using a command python-mode doesn't know about
(e.g. previous-line), so it doesn't have the opportunity to delete the
whitespace. The whitespace module might help here, though I've never used
it. I think the best place for it would be as a write-file-hook though I
worry about it not being aware of Python's triple-quoted strings which can
extend over multiple lines and which might presumably contain legitimate
trailing whitespace. (It might be interesting to have a list of
cursor-motion-hooks which would get called just before point moves, but
that's another story altogether.)
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Just an FYI (haven't posted this to python-dev yet), my problems
with
dangling whitespace are caused by hitting RET or LF
(py-newline-and-indent) which indents according to the current
environment, then moving away from that indentation using a command
python-mode doesn't know about (e.g. previous-line), so it doesn't
have the opportunity to delete the whitespace. The whitespace module
might help here, though I've never used it. I think the best place for
it would be as a write-file-hook

That's the way I use it. There's a machinery to do exactly that in it
already.

though I worry about it not being aware of Python's
triple-quoted
strings which can extend over multiple lines and which might
presumably contain legitimate trailing whitespace.

Gosh:-/ My current changes are: 1/ being able to activate whitespace
cleanup on a per file basis, as well as on a per-mode basis (which is
the only possibility in the current version), and 2/ being able to
select exactly which ones of the 5 kinds of cleanup you want to activate
according to the file / mode you're editing.
Activating trailing whitespace cleanup differently at different places
in the same file/buffer is not going to be trivial. Actually, I don't
think that's whitespace's job anyway.
This sounds to me like a job for mmm-mode. You would have a special
major-mode for editing your triple-quoted strings, and trigger
whitespace cleanup differently according to this, and the other major
modes in your buffer.
--
Read the Jazz Blog !! http://jazzblog.didierverna.com
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

I think the best place for it would be as a write-file-hook though
I worry about it not being aware of Python's triple-quoted strings
which can extend over multiple lines and which might presumably
contain legitimate trailing whitespace.

I note that Tim Peters thinks that (as with MIME quoted printable) the
last character of trailing whitespace should be written \x20 or \x09.
It would be rude to disagree with sweet ol' Uncle Timmy.<wink>
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

(If you do, you might want to get in touch with the python-mode
maintainers Barry Warsaw (barry =at= python org) and/or Skip Montanaro
(skip =at= pobox com). whitespace cleanup has been an issue on Python
lists the last couple of days, and they might be interested.

I'm currently wondering why [whitespace.el] is in text-modes.
Wouldn't it
be better placed in edit-utils ?

Possibly. We have a couple other library moves pending (the json.el
and xml.el stuff in net-utils, for example). I think if we're going
to do it, we may as well try to do as many as possible at once. Any
takers to write up a RFC on reorganizing the stdlib?
Norbert, what do you think? You're most affected by any messing with
package organization.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Didier> So I've just upgraded CVS with my improvements on whitespace.el.
Didier> The documentation at the top of the file is also clearer and
Didier> more complete than before (I hope).
I haven't run from CVS in like forever. Does your change add a
whitespace-describe function? (I reported a bug about it just after your
first post on the subject.)
Skip
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta