5 ms·

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

by mark-r 5y ago

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.

kazinator 5y ago
Because, the tab being fixed at some specific, agreed-upon value is better than it being a moving target. 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?
- TJSomething 5y ago
  The best reason I've seen for tabs is this one [0], where there were two people working on the same code base with different visual impairments, where one person needed 1 space tabs with a very large font and the other had to use 8 space tabs with a very wide monitor. You can't get that functionality if you assume any tab width. [0] https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/ https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...
  - kazinator 5y ago
    I read that bit about the two developers also. It was never explained what the 8-space indent person's visual impairment might be; I suspect that it's a field of vision problem: difficulty tracking vertically between distant elements that are expected to be at the same indentation level. Editors can help here by rendering some vertical lines to guide the eyesight. Nobody should have to resort to huge tabs because of a vertical tracking problem. 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.
    - mark-r 5y ago
      These days our editors are already doing a huge amount of parsing of our code. I know I've seen one editor, probably Visual Studio, that can determine your nesting level and draw vertical lines to delineate it.
- mark-r 5y ago
  I don't think 8 characters was ever an official standard, just a de facto one. The problem is that it's too large for most modern use cases. 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.
  - kazinator 5y ago
    > it's too large for most modern use cases. 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/c/c00.c 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/yacc/source/y1.c 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.

by mark-r 5y ago

kazinator 5y ago

Because, the tab being fixed at some specific, agreed-upon value is better than it being a moving target. 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?

TJSomething 5y ago
The best reason I've seen for tabs is this one [0], where there were two people working on the same code base with different visual impairments, where one person needed 1 space tabs with a very large font and the other had to use 8 space tabs with a very wide monitor. You can't get that functionality if you assume any tab width. [0] https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/ https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...
- kazinator 5y ago
  I read that bit about the two developers also. It was never explained what the 8-space indent person's visual impairment might be; I suspect that it's a field of vision problem: difficulty tracking vertically between distant elements that are expected to be at the same indentation level. Editors can help here by rendering some vertical lines to guide the eyesight. Nobody should have to resort to huge tabs because of a vertical tracking problem. 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.
  - mark-r 5y ago
    These days our editors are already doing a huge amount of parsing of our code. I know I've seen one editor, probably Visual Studio, that can determine your nesting level and draw vertical lines to delineate it.
mark-r 5y ago
I don't think 8 characters was ever an official standard, just a de facto one. The problem is that it's too large for most modern use cases. 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.
- kazinator 5y ago
  > it's too large for most modern use cases. 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/c/c00.c 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/yacc/source/y1.c 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.