On Fri, Feb 7, 2014 at 9:09 AM, Larry Martell <larry.mart...@gmail.com> wrote: > The Tab key is not evil, it's the tab character (Ctrl-I). I have been > bitten by this many time when I had to work on a program written by > another. They had their tab stops set at 5 or 6, mine is set at 4, or > they did not have expandtab set, but I did. So you get either a script > that looks misaligned, but works, or one that does not look misaligned > but doesn't work. When I have to pick up someone else's script the > first thing I do is replace the tabs with spaces.
All you've proven is that *mixing* spaces and tabs is evil. It's like arguing that oil is evil because, when you mix it with water, weird stuff happens. But that doesn't mean I want to fry my bacon in water. Mmm, bacon. Sorry. I'm back now. Ahem. Arguably, a better fix is to replace spaces with tabs, because they're more obvious. But mainly, just be consistent. Whatever one file uses, it uses exclusively. It'd be pretty easy to create a git commit hook that checks files for leading indentation and rejects the commit if it's mismatched; I would guess the same is true in Mercurial. But none of this would solve the OP's original issue. Whether it's a tab or spaces, unexpectedly indenting a line of code is a problem. It's no different from accidentally hitting Ctrl-T in SciTE and reordering two lines, when one line depends on the other. It's a bug. So you look at your commits before you make them (to give yourself a chance to catch it quickly), and you make sure you can always look back over your commits (in case you didn't catch it quickly). Much better than blaming the characters involved. Poor innocent U+0009. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
