[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rfc: (add-hook 'before-save-hook 'delete-trailing-whitespace)
From: |
Neil Jerram |
Subject: |
Re: rfc: (add-hook 'before-save-hook 'delete-trailing-whitespace) |
Date: |
Thu, 21 Jan 2010 20:46:26 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Thien-Thi Nguyen <address@hidden> writes:
> The above form lives in my Emacs init flow, causing trailing whitespace to be
> deleted on `save-buffer' (C-x C-s). For many projects (but not Guile) this
> DTRT, because trailing whitespace is not tolerated. Jim Meyering gives a
> nice rationale in <http://old.nabble.com/whitespace-cleanup-td6828228.html>.
I'm afraid those rationales don't persuade me:
>> - trailing blanks can change the semantics of your code
That's what tests are for.
>> - these differences can lead to unnecessary merge conflicts
Hasn't been a problem in practice AFAIK. I've been doing a lot of
merging at work recently, with a lot of real merge conflicts. The few
that are caused by whitespace are easy to spot, and give me a pleasant
interlude between the ones that are really difficult.
>> - some people use editors that automatically convert / +\t/
>> sequences to just TABs (this is relevant not just for leading
>> indentation, but also for e.g., regular expressions, where
>> it's easy to write a e.g. "[ ]" (space-TAB) as part of a
>> grep or sed pattern. Of course, if you're using a modern
>> enough tool, you can avoid the problem by using "\t". This
>> is why it is better to write the above as "[ ]" (TAB-space).
I can't see why this has to do with _trailing_ whitespace, and it seems
obvious to me that those editors are just broken.
>> - some packages (coreutils :-) have a "make distcheck" rule that will
>> fail if it finds any such offending sequence in its sources.
We don't have that.
> I propose Guile also not tolerate trailing whitespace. What do people think?
If you are concerned that your hook is going to generate diffs that
other developers might think are spurious - I'd say don't worry about
that. I personally won't object to that, and I don't think Andy or Ludo
would either.
If you anticipate some other practical problem, can you say more about
what it is?
Thanks,
Neil