* Thu 2007-10-18 Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Message-Id: 200710180031.54819.dmitry.torokhov@gmail.com
quoted text
> On Wednesday 17 October 2007, Jari Aalto wrote:
>
>> - Any editor will display the text written in "all spaces"
>>   100 % the same. Regradless of any viewer or editor used.
>> 
>> But the same is not true with text that uses tabs (because you
>> really can't know what options the editor is preset / user set /
>> regarding the treatment of tabs).
>> 
>> The score is 1 - 0 for "all spaces" in this contest.
>> 
>
> How about this - I like tabs because when you removing it you
> need to hit Backspace just once and don't have to strain your
> eyes figuring out "Did I delete enough? Does it line up now?"

First I must say that you're right. From user's perspective some things
are convenient and some things not so convenient; it depends:

 a) select an editor where these are no-issues
 b) use an editor that can be configured so that these are no-issues
 c) use the current editor and live by its limitations

I do not speak for any particular project here, just from a general
perspective[1]:

    A project policy QA enforces standards so that everybody can expect
    things to work the same way. The common denominator from view
    perspective (person A, B, C, D ... loads the text into a editor) is
    "all spaces". Similarly if code is post processed, all tools can
    expect that there are no surprises (it's all spaces, no combination
    of spaces and tabs).

The effect of a project policy in general is to enforce standards that
may not necessary match everybody's preferences[2].

Jari

[1] 99 % of the projects do not use Kernel's 8-wide indentation
convention. In all seriously taken editors, the TAB-key is configurable
to move to specific positions; so called "tab stops". Therefore "hit
TAB-key to insert tab character" does not usually apply in coding
context. In coding, the TAB-key is used to control the indentation
level, which is a measure defined in Project policy (coding style).

[2]
The tabs vs spaces issue is simular to those of:

- Starting curly brace placement policy: at EOL, or at separate line
- Identifier naming policy: camelCase vs. dash_names

-- 
Welcome to FOSS revolution: we fix and modify until it shines

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html