Spacing issues

[Ryan Schmidt]

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.