Back when the Tab character was first invented, the indentation was always to a multiple of the 8th column; there was no option for anything else. Not sure why anyone thinks living 50 years in the past is a good idea.
If you use tabs in a plain text document, you know what they are going to do because of the 8 space tab de facto standard.
You could also know what tabs are going to do in a plain text document, if plain text had a standard way to program the tab size. To say, okay, in this line, we have 4 space tabs. Or these specific tab stops at these columns.
But here is no such standard thing; therefore, any tab size option ends up being something that is outside of the representation of the text. It's a setting in the text editor, or terminal or rendering software (e.g. monospaced text to ps/pdf).
The user has to somehow find out what tab size the text "wants", and then configure it. And that tab size fiddling is a sucky waste of time everyone hates; why can't the text just assume 8 so the default works?
[0] https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...
I really think solving the adaptive indentation problem with tabs is a nonstarter. You have to adapt the tools to the reams of existing code, not vice versa.
The editor, in combination with recognizing the syntax of the language to some extent, could treat leading indentation spaces in a flexible "tab like" way. Indentation that is excessive to the visually impaired developer could be reduced by assigning fractional widths to just leading spaces, like 1/8, 1/4 or 1/2 a cell. The editor has to separate indentation spaces from alignment spaces for this purpose.
Another approach could be that, quite simply: the editor groks the indentation and renders it flexibly. It deduces that a certain line of code is three levels indented and then renders that however the user wants, regardless of whether the three levels come from three tabs, 24 spaces, or a mixture of tabs or spaces or whatever.
If the editor knows that two space indentation is in effect, and some line with 30 spaces is deduced to be at four indentation levels, then it knows that eight spaces of that line are rendered as abstract indentation, and the remaining spaces are literal, for alignment.
This is not some Hard Problem in software where we have to throw our hands in the air and conclude that the only way is to achieve the requirements is to have tabs in the data.
These days I find myself using smart editors that combine auto-indenting with tab-to-space conversion. You won't find a tab character in any of my files.
That's just opinion, though; some lunatics think that 8 space indentation is just fine, and they control what goes into the Linux kernel.
Basically, either you think 8 space indentation is fine, or else you regard 8 character tabs as not being suitable for the indentation use case (either you write off the tab entirely, or else subdue its size).
It has nothing to do with modern; programmers revolted at 8 space indentation in 1980 also. Indentation of less than 8 is not a modern trend.
Case study: V6 Unix, 1975.
C compiler uses hard tabs for indentation:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/...
(Was that viewed as 8 spaces though, when edited?)
When we look at Yacc in the same release, we see the germination of the problem of mixed style. Part of the source uses two space indentation. Part of it uses hard tabs. Other conventions also differ:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/...
Yikes! That's exactly the sort of thing that leads to tabs being banned.
> You won't find a tab character in any of my files.
I could almost say the same, except (1) rare accidents happen and (2) some of them are makefiles.