>> if you consistently use spaces, then tabs_to_spaces will >> always give you back your original version; if you consistently use >> tabs, then spaces_to_tabs will give you back your original version. If >> you use some crazy mix of the two, you cannot reconstruct your >> original without remembering where there were tabs versus spaces, > > Just IMO, a crazy mix of tabs and spaces is the only _sane_ thing to > do. Using tabs for the initial indentation, plus spaces for alignment > of function arguments / comments / whatever, is the only way of > getting a layout that will both look right regardless of the tab size, > and allow a viewer to alter the indentation size. That's not what I would call a "crazy" mix of tabs and spaces, but rather a *sane* mix of tabs and spaces. That can consistently be reproduced, and is in fact what the spaces_to_tabs function included above produces. The sane consistent formats as I see it are: 1) use spaces for everything 2) use tabs for indentation, spaces for everything else 3) use tabs for indentation and alignment If you know the tab size, you can reproduce any of these from the others, except that #3 is a little tricky since there's places where the tab/space issue can be ambiguous. I actually think that keeping the repo version with tab-based indentation is a very sane thing to do. However, I'd still like to be able to edit the files using soft tabs, largely because any program that doesn't know what my tab size should be applies its own interpretation and makes the code look terrible (think terminal output for diff, cat, less, etc.) On the other hand, a *crazy* mix of tabs and spaces is where some indentation is done with spaces while other indentation is done with tabs. Even crazier is a single line where the indentation is a mixture of tabs and spaces. I think that just about everyone can agree that this is not only crazy, but evil and is the kind of thing one really wants to avoid in a code base. Unfortunately, when developers disagree on their standard settings, it's very, very hard to avoid precisely this kind of mess. My idea is to enable git to prevent this sort of insanity if configured to do so. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
