Re: [Gnu-arch-users] Whitespace cleanups

[Tom Lord]

    > From: Miles Bader <address@hidden>

    > On Thu, Sep 23, 2004 at 12:42:59AM -0400, James Blackwell wrote:
    > > Under more normal circumstances, I think that most everyone agrees to
    > > avoid this sort of thing. But in this case, I'd like to do it. The 
leading
    > > tabs have gotten to be a bit out of control.

    > Geez, who cares?  Why is doing this worth even _one_ conflict for 
somebody?

Well, it is more _polite_ to avoid leading tabs in the first place for
the simple reason that, (a) in the past at least, some people have
reported that they were unable to configure their editor to display
tabs correctly and (b) the indentation conventions in tla (and most
GNU code) are based on distance measured in spaces, not tabs.

As a point of historical interest, one would probably not have a hard
time finding "older" hackers who use K&R-style (tab-stop-based)
indentation and who would therefore have to reach the opposite
conclusion: that indentation *must* be by tab characters.

    > [There was a `grand whitespace cleanup' in the emacs tree, for
    > no really good reason except that one of the developers was a
    > bit of a whiny pedant, and it was a huge annoyance; some of the
    > repercussions didn't show for like a year: then we tried to
    > merge a big package (Gnus), and -- hey -- 7,000,000 utterly
    > pointless conflicts mixed in with real changes.  What fun _that_
    > was!]

That is a good datapoint and is sufficient to make me not want to
include whitespace changes at this time.

In the early days of tla, when there weren't people doing long-term
(release-spanning) work on branches, one contributor regularly sent me
"whitespace cleanup patches" that were much appreciated -- but times
have changed.

I'm not opposed to eventually doing a wholesale whitespace cleanup
but:

        1) That must wait until we reach a milestone at which it is
           reasonable to not worry so much about ongoing development
           on branches.

        2) It must be done very carefully and accompanied with some
           repeatable "measurements" that show it has been done
           correctly.

        3) I would like the idea of adding "--ignore-whitespace"
           support to be explored before any such large change.
           Perhaps even better would be a patch option that not only
           ignores whitespace, but also rewrites the whitespace of
           added and changed lines to conform to a convention.  Or
           perhaps not.  Regardless, ti seems to deserve some thought
           to me.

But right now, I think Miles is right -- the proposed change is just
asking for trouble for very little gain.

If James wants to continue doing integration work *and* make progress
at eliminating tabs, a safe and reasonable thing that can be done
immediately is to either not accept or to fix any new patches which
introduce tabs.  In other words, if a line of code is added or
changed, the policy can be that the new contents of that line should
not contain tabs.


-t