Jakub Jelinek <ja...@redhat.com> writes: > On Fri, Oct 25, 2024 at 01:25:25PM +0200, Arsen Arsenović wrote: >> 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. > > Editors which are worth a dime handle tabs fine, and I think using tabs is > better.
I agree with the former, but editors aren't the only reason I listed.
WRT the latter, why is that?
> Changing to space would be a major obstackle in git blame/git archeology,
> something lots of people use very often.
Right, me included. Git has ways of dealing with that:
/tmp/foo$ git add test.c
/tmp/foo$ git commit -m untabify
[trunk b5405ab] untabify
1 file changed, 1 insertion(+), 1 deletion(-)
/tmp/foo$ git blame --ignore-rev HEAD test.c
/tmp/foo$ git --no-pager blame --ignore-rev HEAD test.c
^b316ce3 (Arsen Arsenović 2024-10-25 21:38:16 +0200 1) if ()
/tmp/foo$ git --no-pager blame -w test.c
^b316ce3 (Arsen Arsenović 2024-10-25 21:38:16 +0200 1) if ()
Note that the blamed commit is b31, not b54. I'm unsure how well this
works in real-world examples, but it might be sufficient.
Have a lovely night.
> Admittely even this patch which changes 40860 lines isn't very nice, but
> if we had to change 1219139 lines instead (still talking just about
> gcc/, include/, lib{gcc,cpp,iberty,stdc++-v3})...
--
Arsen Arsenović
signature.asc
Description: PGP signature
