> Quouting from that page:
> That ensures that, even if I happened to insert a literal tab in the
> file by hand (or if someone else did when editing this file earlier),
> those tabs get expanded to spaces when I save.
> If you are using a source management system, pretty much *any* source
> management system, doing this will cause all the lines to be "rewritten"
> if they had tabs. The fact that this person would advocate changing
> code that they didn't actually change shows a distinct lack of clue.
Yeah, that recommendation always bugged me too. I would never do that; if
you really want to enforce something like that, the proper place is in a
pre-checkin transform in your source management system so that everything
that actually hits the source management database has no tabs in it. Not
in individual editors.
But the rest of the message is a good summary of the issues, as far as I'm
I'll add one additional issue, and the one that bugs me the most in
practice about tabs. Tabs make patches a pain in the neck to read,
because they change the indentation of the lines in a diff so that it no
longer matches the original indentation. In particularly pathological
cases, they can even make an indented line even with an unintended line.
-- Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/