Arsen Arsenović <ar...@aarsen.me> writes:
> Hi!
>
> Jakub Jelinek <ja...@redhat.com> writes:
>
>> Hi!
>>
>> On top of the previously posted leading whitespace patch, this change
>> just replaces 8 consecutive spaces in leading whitespace by tab.
>> The patch is too large (1MB xz -9e compressed), so I'm not even trying to
>> split it up into 4+ pieces to fit under the mailing list limits.
>> But the change was done purely by a script,
>> for i in `find gcc -name \*.h -o -name \*.cc -o -name \*.c | grep -v
>> testsuite/
>> | grep -v gofrontend/`; do grep -l '^[ ]* ' $i; done > /tmp/2
>> grep -L 'do not edit' `cat /tmp/2` > /tmp/3
>> for i in `find include lib{iberty,gcc,cpp,stdc++-v3} -name \*.h -o -name
>> \*.cc
>> -o -name \*.c | grep -v testsuite/ | grep -v gofrontend/`; do grep -l '^[ ]*
>> '
>> $i; done >> /tmp/3
>> for j in `seq 32`; do for i in `cat /tmp/3`; do sed -i -e 's/^\(\t*\)
>> /\1\t/g' $i; done; done
>> diff -upb yields nothing.
>>
>> Ok for trunk if this passes bootstrap/regtest?
>
> Maybe we should go the other way around?
FWIW, I strongly agree. Tab indentation is an anachronism that I would
love to drop.
Richard
> Compressing eight spaces into
> a tab leads to strange artifacts in diffs (where lines appear
> misindented because some were aligned by tabs and some by spaces), and
> nowadays editor authors seem to have forgotten tabs are eight spaces and
> instead default to (or, worse, hard-code) four, obviously making the
> codebase quite unreadable. We also don't get the benefit of being able
> to adjust tabstop locally to our preferences when we use two-column
> indentation, so I don't see an advantage to keeping 'indent-tabs-mode
> (or equivalent in other editors) enabled.
>
> The only two possible advantages I see currently are:
>
> 1. Emacs behaves this way OOTB; this can be addressed via .dir-locals.el
> 2. Tabs take up less disk space; I do not think this is a real issue
> nowadays
>
> WDYT? Am I missing something?
>
> TIA, have a lovely day.
