On Feb 10, 2007, at 20:58, Vincent Lefevre wrote:
On 2007-02-09 11:39:20 -0600, Ryan Schmidt wrote:
I assume that's due to the stupid setting available in emacs or vi or whatever editor it is that actually encourages that behavior. The one where they've said "We want to indent to 4-space tabs. However, the editor is configured to print 8 spaces for a tab. Therefore, when we want to indent one level, we will use 4 spaces, and when we want to indent 2 levels, we will use one tab, and when we want to indent three levels, we will use one tab and then 4 spaces." And so forth. I'm convinced such an editor setting exists somewhere, because I have seen this nonsense in other projects too, even to the extreme of 2- space indentation. (Indent sequence: 2 spaces, 4 spaces, 6 spaces, one tab, one tab and 2 spaces, etc.)
A mix of tabs and spaces is bad since it won't look right in diffs, for instance.
What do you mean, won't look right in diffs? What do you mean, mix of tabs and spaces? Do you mean mixing tabs at the beginning of a line, as I described in the quoted section above, or do you mean mixing tabs within a line, as in tabs at the beginning, then some text, then spaces to get over to a second column, as I'm suggesting? Or do you mean any use of tabs at all?
Moreover, using tabs only is also a bad choice since one can't align columns and a 8-column space is often too much for a single indentation (even though some editors could be configured to use fewer columns, this is not the case of terminals and web browsers).
Right, tabs are bad for trying to indent additional columns since different editors have different tab sizes.
And tabs are often not preserved in copy-paste.
Copying within an editor should preserve tabs. If you mean copying text out of a Terminal window and trying to paste it, then yes, tabs probably get lost. I think copying out of a web page and pasting into an editor might also convert tabs to spaces, depending on the browser. I hadn't thought of that. That is to say, I've noticed this problem before, but never thought of "don't use tabs, only use spaces" as a solution to it.
No, not really a problem. I would accept extra disk space if this solution brought significant advantages, but I'm saying it brings drawbacks.
I disagree. See above.
Well, you cannot disagree that there is the disadvantage that we all must as a team agree on how many tabs to indent, and that anyone with a differing preference will be out of luck, and that anyone with an editor configured to use tabs will have to jump through some hoops to avoid those tabs now. You may claim that these are not significant drawbacks, and that may be true, but you cannot say that there are no drawbacks at all. Something else to think of if we adopt a convention for spacing and run some automated process to convert all existing portfiles to match this convention: doesn't that make all existing patches in all open bug reports rather difficult to apply? And, nevermind, I think I'm answering my own question: looks like the patch command has an -- ignore-whitespace option which should be just the ticket.