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? 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.
--
Arsen Arsenović
signature.asc
Description: PGP signature
