On Mon, 2003-09-01 at 13:26, Colin Watson wrote: > On Mon, Sep 01, 2003 at 12:53:55PM -0400, Mark Roach wrote: [snip] > > If you think that my goals are incorrect, or can show that it does not > > meet my desires in some way, then tell me how. "X is better than Y" is > > just silly. Perhaps if you gave more information on what constitutes > > "better" we could have an actual discussion. > > Looking back, the reason given for setting tabstop was: > > | So that when we hit tab it goes to the next multiple of... 4? > > If you have a particular goal to accomplish, it makes sense to use > something which accomplishes exactly that goal. The tabstop option is > documented as controlling the "number of spaces that a <Tab> in the file > counts for", while the softtabstop option is documented as controlling > the "number of spaces that a <Tab> counts for while performing editing > operations, like inserting a <Tab> or using <BS>". On the principle of > least surprise, I feel that using an option designed to do the thing I > want, rather than using an option designed to do something else which > happens to do the thing I want as well, is aesthetically better.
I actually just tried sts=4 and it seems to work just fine. I can't say that it is any better a solution (for me) other than the fact that it takes fewer keys to enter manually. I guess I don't really care what the intended purpose behind a feature is as long as it accomplishes my goals. > Also, Steve claimed that tabstop was the only way to do what he wanted > to do. Based on what he'd said about what he wanted to do, I disagreed. I understand now. The way your response was worded - "much better" was the part that didn't make sense to me. After having tried both, they seem functionally equivalent, only with sts obviously being shorter. Taking the effect that "ts=4 et" has on files that use tabs (speaking only in terms of python editing here) into account, I would have to say that I would prefer those files that use tabs to be converted to use only spaces, so it is a nice side effect. There are some cases, such as where a file has a mix of tabs and spaces where doing so can screw stuff up. I think in those cases, the thing to do is bite the bullet and "ts=4 et" anyway and fix it. > As it happens, setting the tabstop option to anything other than 8 does > irritate me when editing files containing tabs. I like to keep source > code within 80 columns, and mismatched tabstop settings have a habit of > screwing that up even if the file doesn't mix tabs and spaces. I've > edited files that were perfectly readable on an 80-column display with > tabstop=4, and were obviously intended that way, but that were > unreadable with a default tabstop. In languages where mixing tabs and > spaces is merely a cosmetic problem, the situation is worse yet. Leaving > the tab character to represent its historical default of eight spaces > simplifies everyone's life and means you can spend your life on more > productive things than worrying about different kinds of whitespace. I can see what you mean. That is part of why I try never to use tabs at all, especially in python code. I think both options have their appropriate uses, and that for python code where it is uncertain what tabs vs spaces will mean in terms of the code operation, spaces-only is a reasonable way to go. Am I still way off the mark? Have I missed some other inherent evilness in converting tabs to spaces? (Mind you, I am speaking only in reference to python coding which is what I thought the conversation was about. if not, my mistake) -Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
