Re: rfc: (add-hook 'before-save-hook 'delete-trailing-whitespace)

[Thien-Thi Nguyen]

() Neil Jerram <address@hidden>
() Thu, 21 Jan 2010 20:46:26 +0000

   > Jim Meyering gives a nice rationale in
   > <http://old.nabble.com/whitespace-cleanup-td6828228.html>.

   I'm afraid those rationales don't persuade me: [...]

Well, i respect the work Jim Meyering does and read his rationale
w/ a more general mindset.  I agree Guile is not GNU coreutils,
and have elided the "does not apply" parts, w/ the exception of:

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

If there is a whitespace policy, we can eliminate those conflicts
(by rejecting non-compliant patches).  This is good!

   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.

I would rather clarify the policy (either way) and then adopt it,
than go w/o policy.  If the policy (either way) is clear, i know
how to avoid introducing spurious diffs and being inconvenienced
by them from others, and can help others do the same.

   If you anticipate some other practical problem, can you say
   more about what it is?

The practical problem is that w/o policy spurious diffs come and
go, instead of being addressed once (one-shot big-commit if policy
is "deny", a blurb in HACKING to justly orient newbies if "allow").
This is "practical" in the sense of "what people will do in
practice".  It is a "problem" in the sense of "i hate burning my
geezer brain-cells on administrivia over and over and over...".

Revised proposal: Let's decide one way or the other, record the
decision (including link to this thread), and bask in the time and
effort saved by our forward thinking when the issue resurfaces w/
new programmers.

thi