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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
