gratuitous changes

gratuitous changes

[Stefan Monnier]

I am responsible for a fair bit of spurious changes in that I often
remove trailing whitespace when I come across it and thus end
up comitting changes to more than the places where I've actually
modified the code.

But I still think that what happened with keyboard.c is bad:
turning every whitespace-only line into an empty line.  This is
bad because hitting TAB somewhere or calling indent-region on
a piece of code will re-introduce those spaces, so we end up
with never ending spurious conflicts.

Please be careful when you commit changes.  Those of us who have
extensive locally modified files (i.e. uncomitted changes)
will be grateful for it.


	Stefan


PS: I'm talking about the following change in keyboard.c:

revision 1.722
date: 2003/01/31 15:23:57;  author: lektu;  state: Exp;  lines: +133 -133
Cygwin support patch.
----------------------------

Re: gratuitous changes

[Andreas Schwab]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

|> But I still think that what happened with keyboard.c is bad:
|> turning every whitespace-only line into an empty line.  This is
|> bad because hitting TAB somewhere or calling indent-region on
|> a piece of code will re-introduce those spaces

If you use M-C-q (c-indent-exp) on an opening brace nearby you won't have
that problem.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gratuitous changes

[John Wiegley]

>>>>> On Fri Jan 31, Andreas writes:

> If you use M-C-q (c-indent-exp) on an opening brace nearby you
> won't have that problem.

whitespace.el also does a great job at keeping whitespace
"normalized".

John

Re: gratuitous changes

[Juanma Barranquero]

On Fri, 31 Jan 2003 16:48:16 -0500
"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> Please be careful when you commit changes.

I *am* careful. I just happen to think that keeping trailing whitespace
around is ugly and a PITA, so I have delete-trailing-whitespace on
write-file-functions.  Even if I took it out, if you maintaing your own
local changes with trailing whitespace you're going to be bitten by it
every now and then.  As you said yourself that you don't like the
whitespace and delete it sometimes, I don't understand why don't keep
your changes that way and save yourself the trouble...

-- 
Juanma Barranquero <lektu@terra.es>

Re: gratuitous changes

[Stefan Monnier]

> I *am* careful. I just happen to think that keeping trailing whitespace
> around is ugly and a PITA, so I have delete-trailing-whitespace on
> write-file-functions.

If we all agree to set things up this way, it's fine.
Otherwise it's a recipe for painful CVS merging.
[ Note: such a setting can introduce subtle bugs with lines ending in
  an elisp space constant such as ?\ , so we have to be careful with it. ]

> Even if I took it out, if you maintaing your own
> local changes with trailing whitespace you're going to be bitten by it
> every now and then.

These were not my trailing whitespaces, but the ones that were in
the file to start with and that you removed in a large scale, thus
introducing conflicts in code that you probably didn't even look at.

> As you said yourself that you don't like the
> whitespace and delete it sometimes, I don't understand why don't keep
> your changes that way and save yourself the trouble...

I don't understand what you're getting at here.

Note that there is in my mind a significant difference between
purely spuriuous whitespace and whitespace which will naturally be
re-introduced by editing (such as whitespace-only lines which will be
reintroduced by the next TAB).
I think the difference is actually not just in my mind: virtually
every file in Emacs CVS has many whitespace-only lines, whereas
most of those files have almost no trailing whitespace on non-empty
lines.

I'm not necessarily opposed to stripping all whitespace-only
line, but then let's do it once and for all in a single commit
so even though it will fuck up `cvs diff' output, I will
at least know how I can trivially resolve all the conflicts.


	Stefan "about 200 locally modified files"

Re: gratuitous changes

[Robert Anderson]

On Fri, 2003-01-31 at 16:00, Stefan Monnier wrote:
> I'm not necessarily opposed to stripping all whitespace-only
> line, but then let's do it once and for all in a single commit

Right.

> so even though it will fuck up `cvs diff' output, I will

diff -w

> at least know how I can trivially resolve all the conflicts.
> 
> 
> 	Stefan "about 200 locally modified files"

In case of emergency, you can write a few-line script to use diff -w and
patch to get the effect of a whitespace insensitive merge.  But, I agree
that automatic, en masse whitespace changes should be done all at once,
or not at all.

If you guys can settle on a policy, I can make "whitespace orthodox" an
automated test.

Bob

PS.  You need a branch about 190 files ago. :)

Re: gratuitous changes

[Stefan Monnier]

> > 	Stefan "about 200 locally modified files"
> PS.  You need a branch about 190 files ago. :)

A sandbox is in many ways a special extra-leightweight branch,
and I do use it that way (I have a couple other sandboxes).

A real branch would have the advantage of making the code available to
other people, but requires more work when merging changes from the
trunk, when committing changes to the trunk and it would be more
difficult to get a meaningful summary of "what's changed w.r.t. the
trunk" which I normally have all the time in my *cvs* buffer.

I guess there is something for CVS, Subversion, MetaCVS, Arch, OpenCM, ...
to learn here, but I'm not sure what,


	Stefan

Re: gratuitous changes

[Robert Anderson]

On Mon, 2003-02-03 at 07:09, Stefan Monnier wrote:
> > > 	Stefan "about 200 locally modified files"
> > PS.  You need a branch about 190 files ago. :)
> 
> A sandbox is in many ways a special extra-leightweight branch,
> and I do use it that way (I have a couple other sandboxes).

Sure.  But editing 200 files is a bit of a heavy lifting task for an
extra-lightweight branch without the features to control those kinds of
extensive changes.

> A real branch would have the advantage of making the code available to
> other people,

That's one advantage, but probably not the central one from my view. 
The central advantage is that I have serious doubts that your 200
changed files comprise one well-defined changeset that fixes bug X or
adds feature Y.  Even if it does implement some kind of large feature or
bugfix, I think if upon commit, a regression or crashing bug was
discovered, you would have quite a large number of possibilities of
where to look for the bug, and, the real problems with large-scale
development in a sandbox - no way of recreating the intermediate steps
you used to get to the code state that was committed.

If instead you had a branch, you could approach your tasks one at a time
without fear of disturbing other developers when it is time to check in
a tentative or intermediate logical changeset.

Why do logical changesets matter?

1)  Because they can be rolled back when bugs appear to isolate the
possible causes, creating ostensibly self-consistent code states at each
step, as opposed to rolling back a file and just hoping the changes in
that file don't depend on other changes in other files.

2) Because it is often the case that branch developers will want to
incorporate some changes from mainline or vice-versa in order to do
their own work more effectively, and doing so with logical changesets
has an order of magnitude less complexity than trying to do so an a
per-file basis.  Not to mention that CVS's complete lack of history
sensitivity for merging makes this a dangerous and confusing task from
the get-go - probably best avoided altogether, which is a shame.

 but requires more work when merging changes from the
> trunk, when committing changes to the trunk and it would be more
> difficult to get a meaningful summary of "what's changed w.r.t. the
> trunk" which I normally have all the time in my *cvs* buffer.

Right.  Because CVS branch support is abysmal, for no good reason other
than historical baggage.

> I guess there is something for CVS, Subversion, MetaCVS, Arch, OpenCM, ...
> to learn here, but I'm not sure what,

Seamless support for branches is central.  Arch, for one, nails this. 
(But neither is it demonstrably ready for prime-time deployment).

Stepping off soap box,
Bob

Re: gratuitous changes

[Juanma Barranquero]

On Fri, 31 Jan 2003 19:00:49 -0500
"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> If we all agree to set things up this way, it's fine.

Well, I think we should agree to maintaing Emacs code in a normalized
way, so these kinds of conflicts (both CVS-wise and people-wise :) get
minimized.

> These were not my trailing whitespaces, but the ones that were in
> the file to start with and that you removed in a large scale, thus
> introducing conflicts in code that you probably didn't even look at.

It was on a large scale only because I checked in the Cygwin patch,
that's large. I, and others, have been commiting changes with trailing
whitespace deleted for months. 

> I don't understand what you're getting at here.

I'm not trying to get anywhere, neither I'm trying to flame or be flamed
at.  I just was expressing my view that we should settle for doing
things the same way (even if it's not my way, yes, but in the issue of
trailing whitespace, seems like the simpler answer, long term).  Sorry
if it came across as angry or whatever.

> Note that there is in my mind a significant difference between
> purely spuriuous whitespace and whitespace which will naturally be
> re-introduced by editing (such as whitespace-only lines which will be
> reintroduced by the next TAB).

There's no such difference in my mind. I have set an underlined face for
the trailing whitespace so I do see it immediately. If I edit something
and accidentally introduce the whitespace, I promptly delete it.

> I'm not necessarily opposed to stripping all whitespace-only
> line, but then let's do it once and for all in a single commit
> so even though it will fuck up `cvs diff' output, I will
> at least know how I can trivially resolve all the conflicts.

I can agree with that.

> 	Stefan "about 200 locally modified files"

Ouch :)

(Summary of my message: I'm really sorry for bringing trouble to you;
but I'd like to fix the "problem" as easily and painlessly as posible.)

-- 
Juanma Barranquero <lektu@terra.es>

Re: gratuitous changes

[Miles Bader]

On Fri, Jan 31, 2003 at 04:48:16PM -0500, Stefan Monnier wrote:
> But I still think that what happened with keyboard.c is bad:
> turning every whitespace-only line into an empty line.  This is
> bad because hitting TAB somewhere or calling indent-region on
> a piece of code will re-introduce those spaces, so we end up
> with never ending spurious conflicts.

This is not true -- indent-region will not add spaces to an empty line, at
least in C or lisp code (it seems to try to preserve whitespace exactly,
which is obviously good for the sort of reason you give in your message).

In fact, emacs indentation commands in general seem to try to delete spaces
from empty lines when possible, e.g., C-j on an empty line filled with spaces
will remove the spaces before inserting a newline and indenting the new line,
and indent-rigidly will remove  spaces from empty lines.

The exception seems to be cases where it's expected that you will immediately
add text to the line, such as TAB, or C-j.  As I expect most people won't
randomly hit TAB on empty lines, I don't think this should be a problem.

> Please be careful when you commit changes.  Those of us who have
> extensive locally modified files (i.e. uncomitted changes)
> will be grateful for it.

This, OTOH, is very true.  I think it's OK to `fix' whitespace issues if they
occur immediately adjacent to a change you're already making, but otherwise
it can be quite annoying for people maintaing patches or CVS branches.

In particular, it's a bad idea to blindly use `delete-trailing-whitespace'
(e.g. in write-file-hooks) on files you're going to check in.

-Miles
-- 
97% of everything is grunge

Re: gratuitous changes

[Bill Wohler]

Miles Bader <miles@gnu.org> writes:

> In particular, it's a bad idea to blindly use `delete-trailing-whitespace'
> (e.g. in write-file-hooks) on files you're going to check in.

  Or more generally, it's a bad idea to change the default value of
  *any* variable that might affect others. If you must do so, create a
  file local variable so that others have the same environment as you.

--
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: gratuitous changes

[Richard Stallman]

    But I still think that what happened with keyboard.c is bad:
    turning every whitespace-only line into an empty line.

I see what you mean.  At the same time, it is tidier
not to have those excess spaces; we don't want to treat
them as sacred.

Re: gratuitous changes

[Martin Stjernholm]

Richard Stallman <rms@gnu.org> wrote:

>     But I still think that what happened with keyboard.c is bad:
>     turning every whitespace-only line into an empty line.
> 
> I see what you mean.  At the same time, it is tidier
> not to have those excess spaces; we don't want to treat
> them as sacred.

I don't know why this got cc'd to the CC Mode address, but I have
something to say on the subject of spurious whitespaces anyway:

The matter of whitespace handling is a personal preference, be it
handling on whitespace on empty lines, other trailing whitespace, or
indent-tabs-mode. While everyone should use whatever settings they
like, it becomes a problem when someone applies his/her preference
over a whole file in a shared development environment, as this thread
has shown.

To address that, I developed the package ws-trim.el. What's special
about it is that it normally only trims whitespace on lines which are
changed through other editing. In my experience this works well; the
code edited by oneself gets the whitespace trimming one likes, while
other code in the same file isn't affected so cvs differences seldom
become unnecessarily large.

The trimming is done whenever the point leaves a line that has been
changed. Editing that affects more than one line, e.g. pasting of
blocks, is normally not affected.

I'm willing to contribute this package if there's interest. (I said
that when I announced it back in -97 too, but RMS thought at that
point that the all-or-nothing approach in whitespace.el was
sufficient.)

Re: gratuitous changes

[Eli Zaretskii]

On 2 Feb 2003, Martin Stjernholm wrote:

> The trimming is done whenever the point leaves a line that has been
> changed. Editing that affects more than one line, e.g. pasting of
> blocks, is normally not affected.
> 
> I'm willing to contribute this package if there's interest.

FWIW, I'm in favor.  I remove trailing whitespace from the parts 
of code I edit as a matter of habit.

Re: gratuitous changes

[Miles Bader]

On Sun, Feb 02, 2003 at 07:52:11AM +0200, Eli Zaretskii wrote:
> > The trimming is done whenever the point leaves a line that has been
> > changed. Editing that affects more than one line, e.g. pasting of
> > blocks, is normally not affected.
> 
> FWIW, I'm in favor.

Me too, but I'm a bit fearful of how it's implemented -- is it
yet-another-entry in post-command-hook, or is it more clever?

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

Re: gratuitous changes

[Martin Stjernholm]

Miles Bader <miles@gnu.org> wrote:

> > > The trimming is done whenever the point leaves a line that has been
> > > changed. Editing that affects more than one line, e.g. pasting of
> > > blocks, is normally not affected.
> > 
> > FWIW, I'm in favor.
> 
> Me too, but I'm a bit fearful of how it's implemented -- is it
> yet-another-entry in post-command-hook, or is it more clever?

It uses after-change-functions, post-command-hook, first-change-hook
and write-contents-hooks. What's the problem with that? Is there a
more "clever" way?

Re: gratuitous changes

[Miles Bader]

On Thu, Feb 06, 2003 at 05:34:03PM +0100, Martin Stjernholm wrote:
> > Me too, but I'm a bit fearful of how it's implemented -- is it
> > yet-another-entry in post-command-hook, or is it more clever?
> 
> It uses after-change-functions, post-command-hook, first-change-hook
> and write-contents-hooks. What's the problem with that?

It slows down editing.  post-command-hook is especially bad because it
happens after _every_ command, even all those little cursor-movement commands
that people expect to be _fast_.  While this is acceptable for localized and
special uses, I think it's good to avoid global (or widespread) use of these
hooks unless it's absolutely possible to do otherwise.  Remember, other
packages could be using them too, and the time adds up!

> Is there a more "clever" way?

I don't know, I haven't really thought about it.

Here's an off-the-top-of-my-head idea though:

Suppose some hook wrapped all the text in a visited file with an appropriate
`modification-hooks' property, which would simply remove itself from any
lines that were modified.  Then the file-write-time hook could scan through
and only remove line-ending whitespace from lines that aren't wrapped by that
property.

This method has the advantage that it only affects text modification, not
cursor movement etc., and it only causes slowdown the first time a particular
piece of text is modified; since most editing is localized, this means it
probably wouldn't have much speed impact at all.

Of course it probably has disadvantages too, but they don't come to mind...
:-)

-Miles
-- 
Quidquid latine dictum sit, altum viditur.


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: gratuitous changes

[Martin Stjernholm]

Miles Bader <miles@gnu.org> wrote:

> > It uses after-change-functions, post-command-hook, first-change-hook
> > and write-contents-hooks. What's the problem with that?
> 
> It slows down editing. /.../

I took care to ensure that they run very fast in the normal case. In
the most common case, i.e. when there has been no preceding
modification, the post-command-hook function only does a single test
of a variable. When there has been a change the overhead still is
negligible compared to on-the-fly font locking. I don't think it's an
issue even on low end systems.

> Suppose some hook wrapped all the text in a visited file with an appropriate
> `modification-hooks' property, which would simply remove itself from any
> lines that were modified.  Then the file-write-time hook could scan through
> and only remove line-ending whitespace from lines that aren't wrapped by that
> property.

That's an alternative. I can see one problem with it: It's not
possible to avoid trimming of multiline edits, e.g. when blocks are
yanked. In my ws-trim package that's configurable.

Besides, the trimming wouldn't take place interactively. Whether
that's a drawback or a feature is of course a matter of taste. I like
the interactive way since it minimizes the experience of the extra
whitespace, i.e. edit a line, leave it, go back again and it'll
already be nice and tidy.

Re: gratuitous changes

[Stefan Monnier]

> The trimming is done whenever the point leaves a line that has been
> changed. Editing that affects more than one line, e.g. pasting of
> blocks, is normally not affected.

That sounds pretty good to me,


	Stefan

Re: gratuitous changes

[Eli Zaretskii]

On Fri, 31 Jan 2003, Stefan Monnier wrote:

> I am responsible for a fair bit of spurious changes in that I often
> remove trailing whitespace when I come across it and thus end
> up comitting changes to more than the places where I've actually
> modified the code.
> 
> But I still think that what happened with keyboard.c is bad:
> turning every whitespace-only line into an empty line.

I generally dislike unnecessary whitespace changes as well: for one 
thing, they make diffs much harder to grasp.

However, I must say that when I brought up this issue in the past in the 
context of Emacs development, most of other developers didn't feel it was 
that bad.  So, as extreme as this particular case is, at least in 
principle, Emacs development does not seem to discourage such gratuitous 
changes.  At least it didn't until now.

Re: gratuitous changes

[Juanma Barranquero]

On Sun, 2 Feb 2003 07:56:18 +0200 (IST)
Eli Zaretskii <eliz@is.elta.co.il> wrote:

> I generally dislike unnecessary whitespace changes as well: for one 
> thing, they make diffs much harder to grasp.

Only because there are a lot of files with trailing whitespace inserted
casually and carelessly. If we implemented a policy of stripping it when
we find it, in a short time there would me no more conflicts about the
issue.

> So, as extreme as this particular case is, at least in 
> principle, Emacs development does not seem to discourage such gratuitous 
> changes.  At least it didn't until now.

That's for sure. As I've said, I've had the hook for taking out the
whitespace for a year and I've been commiting "trimmed" files since back
then.  And I'm pretty sure there are other developers who rutinely do
the same.  Not a single complain till now, IIRC.

-- 
Juanma Barranquero <lektu@terra.es>

Re: gratuitous changes

[Kim F. Storm]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On Fri, 31 Jan 2003, Stefan Monnier wrote:
> 
> > I am responsible for a fair bit of spurious changes in that I often
> > remove trailing whitespace when I come across it and thus end
> > up comitting changes to more than the places where I've actually
> > modified the code.
> > 
> > But I still think that what happened with keyboard.c is bad:
> > turning every whitespace-only line into an empty line.
> 
> I generally dislike unnecessary whitespace changes as well: for one 
> thing, they make diffs much harder to grasp.

And merging a nightmare.  Making cosmetic changes to source code
on the trunk of a CVS project tree often makes it much harder to merge
changes from a branch to the trunk.  E.g. when it's time to merge the
emacs unicode branch to the head, there is a bigger risk of merge
conflicts in code which really doesn't differ except for white space.

> 
> However, I must say that when I brought up this issue in the past in the 
> context of Emacs development, most of other developers didn't feel it was 
> that bad.  So, as extreme as this particular case is, at least in 
> principle, Emacs development does not seem to discourage such gratuitous 
> changes.  At least it didn't until now.
> 

Maybe because we have been spared from the troubles of large-scale
merging of branches...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gratuitous changes

[Richard Stallman]

Would someone like to go through all the files systematically
doing nothing except getting rid of spurious whitespace?
That way we would not have to study those diffs at all,
and the job would be out of the way.

Re: gratuitous changes

[Juanma Barranquero]

On Mon, 03 Feb 2003 08:01:06 -0500, Richard Stallman <rms@gnu.org> wrote:

> Would someone like to go through all the files systematically
> doing nothing except getting rid of spurious whitespace?

I'll do, if no one opposes to the change.


                                                           /L/e/k/t/u

Re: gratuitous changes

[Stefan Monnier]

> > Would someone like to go through all the files systematically
> > doing nothing except getting rid of spurious whitespace?
> I'll do, if no one opposes to the change.

You might want to do the same on the unicode branch.


	Stefan

Re: gratuitous changes

[Juanma Barranquero]

On Mon, 03 Feb 2003 09:54:21 -0500, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> You might want to do the same on the unicode branch.

Yeah, of course. Is there any other branch worth the effort?


                                                           /L/e/k/t/u

Re: gratuitous changes

[Juanma Barranquero]

On Mon, 03 Feb 2003 08:01:06 -0500, Richard Stallman <rms@gnu.org> wrote:

> Would someone like to go through all the files systematically
> doing nothing except getting rid of spurious whitespace?

I've finished removing the whitespace on the trunk, so if someone was
waiting for the barrage of commits to end, you can go now :)

I'll do the same on the unicode branch ASAP, but it can take a while
(not more of 24 to 48 hours).


                                                           /L/e/k/t/u

Re: gratuitous changes

[Robert Anderson]

On Tue, 2003-02-04 at 06:59, Juanma Barranquero wrote:
> On Mon, 03 Feb 2003 08:01:06 -0500, Richard Stallman <rms@gnu.org> wrote:
> 
> > Would someone like to go through all the files systematically
> > doing nothing except getting rid of spurious whitespace?
> 
> I've finished removing the whitespace on the trunk, so if someone was
> waiting for the barrage of commits to end, you can go now :)

Hmm.  Didn't you just multiply by N times the problem Stefan was worried
about?

Maybe if you provided the method that you used to get rid of the
whitespace, people with checked out files can apply the script to their
sandboxes to minimize the headaches this will cause when they try to
update.

Bob

Re: gratuitous changes

[Juanma Barranquero]

On 04 Feb 2003 08:09:46 -0800, Robert Anderson <rwa@alumni.princeton.edu> wrote:

> Hmm.  Didn't you just multiply by N times the problem Stefan was worried
> about?

Perhaps my ability to read English prose is failing me again; I thought
I was doing just what Richard asked for...

> Maybe if you provided the method that you used to get rid of the
> whitespace, people with checked out files can apply the script to their
> sandboxes to minimize the headaches this will cause when they try to
> update.

Script?

Basically, I edited every single file and did

 M-x delete-trailing-whitespace [ret]
 C-x C-s [ret]
 C-x k [ret]

with the caveats that I only edited meaningful files, and I took into
account the encoding (so I didn't end screwing files in
iso-2022 or whatever).

                                                           /L/e/k/t/u

Re: gratuitous changes

[Robert Anderson]

On Tue, 2003-02-04 at 08:44, Juanma Barranquero wrote:
> On 04 Feb 2003 08:09:46 -0800, Robert Anderson <rwa@alumni.princeton.edu> wrote:
> 
> > Hmm.  Didn't you just multiply by N times the problem Stefan was worried
> > about?
> 
> Perhaps my ability to read English prose is failing me again; I thought
> I was doing just what Richard asked for...

You did, but perhaps it would have been polite to confer with Stefan
first, to have the best timing on it.

> > Maybe if you provided the method that you used to get rid of the
> > whitespace, people with checked out files can apply the script to their
> > sandboxes to minimize the headaches this will cause when they try to
> > update.
> 
> Script?
> 
> Basically, I edited every single file and did
> 
>  M-x delete-trailing-whitespace [ret]
>  C-x C-s [ret]
>  C-x k [ret]
> 
> with the caveats that I only edited meaningful files, and I took into
> account the encoding (so I didn't end screwing files in
> iso-2022 or whatever).

IMO, that was not the optimal way to do it, both because it wasted your
time and it makes it harder for people to do a parallel change without
wasting their own.

If someone wanted to mirror those changes in a sandbox or branch to
prevent update or merge problems, they would probably have a hard time
figuring out what you mean by "meaningful files", and they certainly
don't want to press those keystrokes hundreds if not thousands of times.

Food for thought:  a script would have left a precise prescription for
what you did that was trivially applicable to other branches as well as
sandboxes to prevent the kinds of merge and update problems this was
trying to minimize.

Bob

Re: gratuitous changes

[Juanma Barranquero]

On 04 Feb 2003 09:14:09 -0800, Robert Anderson <rwa@alumni.princeton.edu> wrote:

> You did, but perhaps it would have been polite to confer with Stefan
> first, to have the best timing on it.

I asked if anyone opposed the change in any way, and no one did. I asked
about branches, and Stefan answered in private mail about the issue. I
haven't heard a single voice (till now) saying "wait". I honestly don't
think I'm being impolite.

> IMO, that was not the optimal way to do it, both because it wasted your
> time and it makes it harder for people to do a parallel change without
> wasting their own.

IMO, that was the optimal way to do it, because I got to decide what
files and how to change, instead of relying in a mindless bulk
substitution of some sort (even if the script has a lot of inteligence).

> Food for thought:  a script would have left a precise prescription for
> what you did that was trivially applicable to other branches as well as
> sandboxes to prevent the kinds of merge and update problems this was
> trying to minimize.

And more food for thought: I have a few years of experience in
programming, I've got some tools (Perl among them) at hand, and still I
decided to do by hand what is undoubtedly a very boring task...

Anyway, the Unicode branch is still unchanged.  If you have a better
method, by all means, go for it.  I'd *love* for you to do the change
with a script and save me the effort.

                                                           /L/e/k/t/u

Re: gratuitous changes

[Eli Zaretskii]

> Date: Tue, 04 Feb 2003 15:59:48 +0100
> From: Juanma Barranquero <lektu@terra.es>
> 
> I've finished removing the whitespace on the trunk

Hmm... did we really agree on doing that on such a broad scale?  I
mean, the *.[ch] files should indeed be stripped of trailing blanks,
as well as the *.el files.  But simple text files such as INSTALL* and
README*, or the *.texi files, or even texinfo.tex and termcap.src
(which are imported from elsewhere)?  Jeez...

Re: gratuitous changes

[Juanma Barranquero]

On Tue, 04 Feb 2003 21:46:42 +0200
"Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> Hmm... did we really agree on doing that on such a broad scale?

In fact, I'm starting to think "we", whomever this "we" is, didn't agree
to anything because there aren't any things which "we" could agree on.

-- 
Juanma Barranquero <lektu@terra.es>

Re: gratuitous changes

[Stefan Monnier]

> > Hmm... did we really agree on doing that on such a broad scale?
> 
> In fact, I'm starting to think "we", whomever this "we" is, didn't agree
> to anything because there aren't any things which "we" could agree on.

Come on guys, let's move on,


	Stefan "really sorry he caused all this"

Re: gratuitous changes

[Nick Roberts]

I haven't really followed this thread but the 20 resulting changes to
gdb-ui.el present no problem to me. I have seen a feature of XEmacs that helps
prevent trailing white space: the cursor becomes more narrow when its at the
end of a line.  Would it be a good idea for Emacs? (Apologies if this point
has already been made)

Nick

Re: gratuitous changes

[Edward O'Connor]

My $0.02 regarding removing extraneous whitespace, ?\ , etc:

It seems like the occurances of ?\ and ?\	 (?\SPC and ?\TAB)
in source files is probably pretty minimal. In the particular
case of ?\	, we have a perfectly good and arguably more
readable substitute in ?\t, so why don't we adopt a good and
arguably more readable substitute for ?\ , say, ?\s?


Ted, who thinks (setq foo ?\ ) looks strange

-- 
Edward O'Connor
ted@oconnor.cx

Ense petit placidam sub libertate quietem.

Re: gratuitous changes

[Juanma Barranquero]

On Tue, 04 Feb 2003 17:59:57 -0500
"Edward O'Connor" <ted@oconnor.cx> wrote:

> so why don't we adopt a good and
> arguably more readable substitute for ?\ , say, ?\s?
> 
> Ted, who thinks (setq foo ?\ ) looks strange

I like it. I find ?\  weird too, and ugly.

-- 
Juanma Barranquero <lektu@terra.es>

Re: gratuitous changes

[Kim F. Storm]

"Edward O'Connor" <ted@oconnor.cx> writes:

> My $0.02 regarding removing extraneous whitespace, ?\ , etc:
> 
> It seems like the occurances of ?\ and ?\	 (?\SPC and ?\TAB)
> in source files is probably pretty minimal. In the particular
> case of ?\	, we have a perfectly good and arguably more
> readable substitute in ?\t, so why don't we adopt a good and
> arguably more readable substitute for ?\ , say, ?\s?
> 

AFAIK, there is no difference between "?\ " and "? ".

I'd like to "see" the space too, but \s is a bad choice.
Maybe ?\_ could identify this?

There are many ways to express a "protected space":

        ? ;  -- only works at end of line
        (+ ? )
        32
        (aref " " 0)
        (string-to-char " ")

In any case, ?\_ looks simpler.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gratuitous changes

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> I'd like to "see" the space too, but \s is a bad choice.

Before you ask why, let me answer:  \s is already used,
e.g. ?\s-a is the "super" modifier applied to a.
 
-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gratuitous changes

[Kenichi Handa]

In article <5xfzr3tvau.fsf@kfs2.cua.dk>, storm@cua.dk (Kim F. Storm) writes:
> storm@cua.dk (Kim F. Storm) writes:
>>  I'd like to "see" the space too, but \s is a bad choice.

> Before you ask why, let me answer:  \s is already used,
> e.g. ?\s-a is the "super" modifier applied to a.
 
If ?\s is not followed by `-', it causes the error "Invalid
escape character syntax".  And, in the case we use ?\s for a
space character, it is certainly not followed by `-'.  So, I
think there's no prblem in introducing this new syntax.

But, I myself think it is better to find another solution
because ?\s is too cryptic to be introduced newly.  Or, I
think just ?\040 or ?\x20 is good enough even if it depends
of ASCII encoding.  At least it is better than 32 because it
conceptually represents a character, not a number.

---
Ken'ichi HANDA
handa@m17n.org

Re: gratuitous changes

[Luc Teirlinck]

Kim Storm wrote:

   AFAIK, there is no difference between "?\ " and "? ".

No, but the Elisp manual says:

    Also add a backslash before whitespace characters such as space,
    tab, newline and formfeed.  However, it is cleaner to use one of
    the easily readable escape sequences, such as `\t', instead of an
    actual whitespace character such as a tab.

The last sentence might provide some further argument for ?\_, which I
still believe to be clearer than ?\s, because the latter could provide
human confusion with ?\s-, even though there might be no syntactic
conflict.

Sincerely,

Luc.

Re: gratuitous changes

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> The last sentence might provide some further argument for ?\_

I'd go for that; ?\_ seems more obvious to me than other suggestions.

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: gratuitous changes

[Richard Stallman]

    readable substitute in ?\t, so why don't we adopt a good and
    arguably more readable substitute for ?\ , say, ?\s?

(string-to-char " ") would also work, and would avoid
the need for a change in Emacs.

Re: gratuitous changes

[Luc Teirlinck]

Richard Stallman wrote:

   (string-to-char " ") would also work, and would avoid
   the need for a change in Emacs.

This works, but in certain situations, one may want something more
concise.  Within lists and arrays, (string-to-char " ") requires
backquote and comma.  Note that danger of accidental tabification
occurs everywhere, including lists, arrays and strings.  I now lean
toward promoting one of Handa's two suggestions: ?\040 or ?\x20.  They
also require no change in emacs, nor use of backquote-comma, and are
more concise than (string-to-char " ").

Use of ? and ?\ does not appear safe, without change in `tabify-regexp'.
Of course, there also is the possibility of changing `tabify-regexp'.

Sincerely,

Luc.

Re: gratuitous changes

[Richard Stallman]

       (string-to-char " ") would also work, and would avoid
       the need for a change in Emacs.

    This works, but in certain situations, one may want something more
    concise.  Within lists and arrays, (string-to-char " ") requires
    backquote and comma.

Yes, but that case may never occur.  Character constants `?\ '
are rare enough to begin with, and we only have a problem when
they occur at the end of the real code in a line.

Re: gratuitous changes

[Juanma Barranquero]

On Tue, 4 Feb 2003 20:44:48 +0000
Nick Roberts <nick@nick.uklinux.net> wrote:

> I have seen a feature of XEmacs that helps
> prevent trailing white space: the cursor becomes more narrow when its at the
> end of a line.  Would it be a good idea for Emacs?

Perhaps.

OTOH, on 21.3.50 it is already easy to keep track of it:

  (when (facep 'trailing-whitespace)
    (setq-default show-trailing-whitespace t)
    (set-face-attribute 'trailing-whitespace nil
                        :foreground "red"
                        :background "black"
                        :underline t))

or whatever other face setting that makes it stand out clearly.

-- 
Juanma Barranquero <lektu@terra.es>

Re: gratuitous changes

[Stefan Monnier]

> > I have seen a feature of XEmacs that helps
> > prevent trailing white space: the cursor becomes more narrow when its at the
> > end of a line.  Would it be a good idea for Emacs?

It might be a good idea for another reason: it could help us solve
the problem of "where do we put the cursor when it's at the
end of a line that's exactly the width of the window" (right now, we
put it on the next line, which means that we end up with an empty line
for no other reason than to put the cursor there every other blue moon).


	Stefan

Re: gratuitous changes

[Eli Zaretskii]

On Tue, 4 Feb 2003, Nick Roberts wrote:

> I haven't really followed this thread but the 20 resulting changes to
> gdb-ui.el present no problem to me. I have seen a feature of XEmacs that helps
> prevent trailing white space: the cursor becomes more narrow when its at the
> end of a line.  Would it be a good idea for Emacs?

We have the trailing-whitespace face to show that instead.  It has the 
advantage of showing junk whitespace regardless of the cursor position.  
In fact, it shows it _only_ if the cursor is not at the end of the 
trailing whitespace.

But I agree with Stefan: that special cursor shape might be useful for 
other purposes (although I suspect that the change in the redisplay code 
he suggests is not a trivial one).

Re: gratuitous changes

[Richard Stallman]

    I haven't really followed this thread but the 20 resulting changes to
    gdb-ui.el present no problem to me. I have seen a feature of XEmacs that helps
    prevent trailing white space: the cursor becomes more narrow when its at the
    end of a line.  Would it be a good idea for Emacs? (Apologies if this point
    has already been made)

I think Emacs already has some kind of feature to show trailing
whitespace, but I forget the details of it and what it is called.

Re: gratuitous changes

[Luc Teirlinck]

Richard Stallman wrote:

   I think Emacs already has some kind of feature to show trailing
   whitespace, but I forget the details of it and what it is called.

show-trailing-whitespace

Sincerely,

Luc.

Re: gratuitous changes

[Juanma Barranquero]

On Tue, 04 Feb 2003 15:22:25 -0500
"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> 	Stefan "really sorry he caused all this"

Honestly, you don't have anything to be sorry about. It wasn't you who
caused all this, it was me.

-- 
Juanma Barranquero <lektu@terra.es>

Re: gratuitous changes

[Eli Zaretskii]

On Tue, 4 Feb 2003, Juanma Barranquero wrote:

> > Hmm... did we really agree on doing that on such a broad scale?
> 
> In fact, I'm starting to think "we", whomever this "we" is, didn't agree
> to anything because there aren't any things which "we" could agree on.

"We" means Richard who asked you to do this and all the other developers 
(including myself) who didn't object ;-)

I'm sorry if my message sounded a bit harsh: I didn't mean that.  I'd 
like to thank you for the mundane job well done, first and foremost.  I 
was just surprised to see some files touched by this which I didn't 
expect you to change, like the old ChangeLog.* files, ONEWS.*, 
texinfo.tex, etc.  But if no one sees that as a problem, I don't mind 
either; I just wanted to raise the point before it is buried under the 
dust.

Re: gratuitous changes

[Juanma Barranquero]

On Wed, 5 Feb 2003 08:01:01 +0200 (IST), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> I'm sorry if my message sounded a bit harsh: I didn't mean that.

No, it's me who's a little jumpy. Sorry.

> I was just surprised to see some files touched by this which I didn't 
> expect you to change, like the old ChangeLog.* files, ONEWS.*, 
> texinfo.tex, etc.

I thought about it before doing the change, but the rationale was that
they're still in the sources and get modified every now and then (admitedly,
INSTALL is modified less often than, say, files.el :), so the problem
about new commits causing conflicts exists for them too (albeit on a
very minor scale).

I admit I got a bit carried on with texinfo.tex, termcap.src, etc., but
anyway, if they're upgraded they probably will be wholesale, so that's
no problem either IMO.

> I just wanted to raise the point before it is buried under the 
> dust.

The dust formed by the corpses of so many innocent bits who died on the
Great Whitespace Commit Frenzy, you mean? ;)


                                                           /L/e/k/t/u

Re: gratuitous changes

[Eli Zaretskii]

> Date: Wed, 05 Feb 2003 09:18:47 +0100
> From: Juanma Barranquero <lektu@terra.es>
> 
> > I just wanted to raise the point before it is buried under the 
> > dust.
> 
> The dust formed by the corpses of so many innocent bits who died on the
> Great Whitespace Commit Frenzy, you mean? ;)

No, the dust of time and our failing memories ;-)

Re: gratuitous changes

[Thien-Thi Nguyen]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

   No, the dust of time and our failing memories ;-)

just committed admin/notes/trailing-whitespace to help indefinitely
extend the mtbForgetting...

thi

Re: gratuitous changes

[Richard Stallman]

    I've finished removing the whitespace on the trunk, so if someone was
    waiting for the barrage of commits to end, you can go now :)

I've never seen so many commit messages for such a short time.

Re: gratuitous changes

[Francesco Potorti`]

>But I still think that what happened with keyboard.c is bad:
>turning every whitespace-only line into an empty line.

I use a hook that deletes useless white space from text and program
sources whenever a file is saved, apart from white space at the cursor.

And I always call diff with the -b option.

The latter should avoid all problems you mention when merging
differences. 

Re: gratuitous changes

[Miles Bader]

Francesco Potorti` <pot@gnu.org> writes:
> And I always call diff with the -b option.
> 
> The latter should avoid all problems you mention when merging
> differences. 

Um, no.  `diff -b' is only appropriate when generating patches for
humans to look at*, not for merging (and things like CVS don't allow such
behavior anyway).

* and even then, it's not always appropriate -- sometimes you _want_ to
  see indentation changes or whatever

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: gratuitous changes

[Francesco Potorti`]

>Um, no.  `diff -b' is only appropriate when generating patches for
>humans to look at*, not for merging (and things like CVS don't allow such
>behavior anyway).

Uh.  I meant that, when looking at diffs, I always use -b.  When
merging, spaces have never affected me, because ediff and emerge tell
you where the difference is, and even let you know when a diff is only
made of whitespace.

This is not to say that the annoyance is not there, just to say that you
can overcome it quite easily, and in my case it never bothered me, as
far as source code is concerned, but YMMV.