guile-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]