Once upon a time computers were not so wide-spread as they are today, but yet using Tab characters then was much simpler. Why ? Everybody knew what the size of a tab character was. At the beginning, the tab size was 8.
You can still see this today. Printers could receive input text directly on the printer port (usually a parallel port or a serial port (RS-232C)), and print it in a manner similar to a console or terminal, so without formatting and without a word processor, like the one from Microsoft. I believe many printers can still do this today, and if you can identify the printer port by name, you can use the copy command to print a text file. Printers used a tab size of 8, and nobody questioned it, because they had no reason to.
Terminals and console emulators were created, and again there was no need to "choose" a tab size, when the answer was already there: a tab character stands for "the next multiple of 8 spaces" (the next tab stop). Yes, "Tab size" is only a shorthand notation for "distance between tab stops", so a tab size of 8 really mens a new tab stop at every 8 character columns.
The Tab was first meant to be used for tables. Then people wanned to use it to save spaces. That was ok, things were still good. But then they wanned to use it for indentation. And then indenting the source code. And this is were it begins.
You can see how an indentation of 8 would be inconvenient, especially on early monitors that were limited in size and resolution. Nonetheless, some people did it, they used an indent size of 8, though I figure it was not pleasent.
By now, the idea of making the changing default Tab size might even look good ...
It never was !
Why ? Well it solves an immediate problem, for a specific issue: indentation size in source code. But after the immediate problem is solved, you begin to see the other problems:
the resulting file depends on this choice, if you want to read it the same way it was written
consoles and printers do not have this choice and can no longer display your text as intended
other people may not have this choice, if they do not have your text editor or software tools
if you move to other projects, you will no longer have this choice, as you will need to match their choice instead
In short, the immediate problem was solved, but things were ... still wrong. In short the solution was an "incompatibility", it worked only for you or maybe your project. But not for everybody else.
However I can see how people still liked the idea of using tabs to save spaces. I mean I still like it, and today there is no need to save spaces characters whatsoever !
So unfortunately they kept doing this and all text editors and IDEs now have the option to change tab size. The option itself is good, but the default value was not ! A large part of them have a default tab size that:
does not keep compatibility (no longer 8), but
is suitable for indentation (for source code, as usual).
Especially Microsoft (with Visual Studio), and more recently Eclipse, were using the Tab size of 4. And the worse part is, when a product (or company) chooses the default Tab size, later they want to stick with it, to keep compatibility with the previous versions. So after breaking with the old Tab size, now they value backward compatibility !
So at the time, what else could people then have done ? Was there a better way ?
There ... was a solution ! I can only wish that companies would have reached a consensuns about it. The solution is to:
give the people what they need -- indentation based on tabs, that is convenient, like with a tab size of 4.
at the same time keep the Tab at the size unchanged -- to stay compatible with terminals, printers and other software.
So the solution is to keep the indent size independent of the tab size. How to have an indent size of 4 with a tab size of 8 ? By always using the optimum mix of tabs plus spaces, to achieve any indentation. Like using 1 Tab plus 4 spaces to achive indentation level 3 (that is, 3 x 4 = 12 character columns).
Now some people got so used to changing Tab size, even on the fly, that now they find it messy to use a mix of tabs and spaces for indentation. But I would argue that changing the default Tab size created the bigger mess in the first place.
I mean how much of an advantage is it for you be able to change the Tab size, just so you can play with it ? Is there any benefit from the freedom of switching existing text to 5 spaces instead of 4 ? Or at 3 ?
Plus I bet this "feature" rarely works for real, as it depends on the original text being carefully written to only use tabs, from top to bottom. In my experience spaces always tend to creep in , because:
visually they can not be easily distinguished from the tabs, in most cases anyway.
moving the cursor through tabs makes it skip columns in most editors, and sometimes you just need to place the cursor halfway through to change the indent level of a line
Even today, you can not really choose the size, as long as you want to work in a team and in a company. Most software companies do what they do best: avoid the problem in the easiest way possible. They require everyone to go back to spaces only.
Which is just not smart. I mean it is not solving the problem, it is avoiding it. And if you want to impose a style, you might as well include the Tabs. What fixes problems for the company in this case is mandating the same style everywhere, but the actual choice is not that important.
The point is, you only rarely have a true choice (a free choice) of Tab size, end even if you do, it is not all that usefull. You still want to indent at 4 spaces for the most part. In this case, the "choice" is more of an illusion, or at best a play thing, but this "choice" has created a real mess for a long time now.
So I would argue that mixing tabs with spaces, and keeping the compatible tab size of 8, is still the way to go. It's not gonna hurt you or chip away at your freedom. But it can be a mean to return to the simple ways things used to be.
So what is the best way forward then ?
Well it looks like editor and IDE support is what can save the day, and answer the questions of tab size and tabs vs. spaces. The best way forward consists of two or three parts:
support for automatic, per-project, tab size and indent size settings, instead of global settings in the editors and IDEs.
support for independent indent size and tab size, across all major editors and IDEs. Most of them have this, some of them do not, notably Microsoft Visual Studio Code.
improve diff support for text with tabs across some tools and online platforms. Because the diffs insert an extra column with the generated '+', '-' or ' ' characters in front of the text, see below.
The idea is to have the option to load Tab size and indent size automatically in the IDE or the editor, and set it once, for the entire project and the entire team. The EditorConfig specification has slowly gone a long way to achieve this goal. I believe Eclipse has per-project Tab size as well. Vim has plugins for that also.
Once we have that, it will be easy for everyone to go back to a common default, namely to the tab size of 8 and indent size of 4, without affecting other projects, teams or global settings in the editors and IDEs. One person can freely work on two projects with different settings in this way.
So once we reach this point, we can finally reach the promised land and have the best of both worlds everywhere:
a common default across all software -- tab size of 8
convenient use of tabs for indentation -- indent size of 4
So why should 8 be the one true answer for tab size ? Well it does have something: the console. The command line is still used today more often then people like to think.
For some people having a functional terminal is just something nice. But for others, it is significant, it is a productivity issue. So lets just say there is something really nice about:
being able to show a small script in the terminal and have it look just right, like in the IDE, with no concern for tabs. Or maybe a file header, with the Unix `head` command
showing the results from FindStr or `grep` commands. Search is important.
showing position markers (usually the caret ^) for compiler error messages, and have them line up correctly in the console.
And there is some comfort in knowing you made the choice that would still work with the early operating systems and terminal emulators, if anyone were to use them. That your work is still compatible with the rest of the world, as it should be.
Like many others, I use `git diff` command a lot in the terminal. The ability to show diffs right in the terminal is important. By their nature, unified diffs insert a column with the + and - signs in front of lines being added and removed. This shifts all of the text to the right by one column. But not the tab stops. So it messes up with tab stop positions. Some tools like git gui and gitk know to do the right thing, and they show diff text with the tab stops shifted to the right by one as well, to match the shift in text.
Other tools have support for this:
you can set core.pager in git command line, or the GIT_PAGER environment variable, to "less -x9,17,25,33" to fix diff output
you can set vartabstop=9,8 in Vim, and it is easy to write a small addition to the syntax file for diff files, and put it in the user config directory
In general any editor that allows "variable" tab stops should be able to show unified diffs properly with the right settings.
But others do not (yet), for example online platforms like github (again from Microsoft) have only limited settings and can not be configured by users.
So in the end, like I said it is good software support, across the board, that appears to be the solution for Tab issues.