News for hackers. Stuff that matters.
Re:But no, 80-column terminals in 2020 isn't “reasonable” an... by briandilley on Friday May 29, 2020 @07:19PM (#23356727)
I wonder how Linus feels about tabs vs. spaces (I didn't read the entire post, so maybe he addressed it?)
Re:But no, 80-column terminals in 2020 isn't “reasonable” an... by mariocesar on Friday May 29, 2020 @07:20PM (#23356741)
> And yes, we do use wide tabs, because that makes indentation something you can visually see in the structure at a glance and on a whole-function basis, rather than something you have to try to visually "line up" things for or count spaces.

That is what he says

Re:But no, 80-column terminals in 2020 isn't “reasonable” an... by billsnow on Friday May 29, 2020 @07:24PM (#23356781)
In the post he refers to "wide tabs" which means hard tabs displayed 8 chars long. This has been the standard kernel style since the beginning.
Re:But no, 80-column terminals in 2020 isn't “reasonable” an... by saagarjha on Friday May 29, 2020 @07:21PM (#23356746)
The kernel uses 8-space tabs.
Re:But no, 80-column terminals in 2020 isn't “reasonable” an... by ccmcarey on Friday May 29, 2020 @07:34PM (#23356876)
How do you mean 8 space tabs? Are tabs not single characters \t?
Re:But no, 80-column terminals in 2020 isn't “reasonable” an... by ordu on Friday May 29, 2020 @07:38PM (#23356902)
You can customize your text editor to show them as any number of spaces. Mostly people prefer tab-stops at each forth or eighth column.
Re:But no, 80-column terminals in 2020 isn't “reasonable” an... by dezgeg on Friday May 29, 2020 @08:05PM (#23357119)
In practice you get problems, because of the line length rule.

I.e. if your editor is configured with four-space tabs and a line with one leading tab shows up in your editor having 79 characters, it will show up as 83 characters for others assuming the normal 8-space tabs thus breaking the line length rule.

Not to mention that coding style may require that function calls broken to 2 lines must have the arguments aligned at the opening parenthesis.

For example, breaking up foobarbaz(1, 2); into two lines would require having the second line start with <TAB><SPACE><SPACE>2); which would no longer look correct with 4-space tabs.

Re:But no, 80-column terminals in 2020 isn't “reasonable” an... by eMSF on Friday May 29, 2020 @09:12PM (#23357527)
>Not to mention that coding style may require that function calls broken to 2 lines must have the arguments aligned at the opening parenthesis.

That doesn't result in any problems with using <TAB>s, unless the coding style also requires you to replace all (leading) sequences of N spaces with with a <TAB>, which is, IMO, quite brain-dead. For example,

    if (cond) {
    <TAB>foo(1,
    <TAB><SP><SP><SP><SP>2);
    }
looks fine regardless of the width of <TAB>.

Admittedly, your first problem remains; a problem with dumb editors. In truth, your editor could well signal if your lines exceed the limit (indent-width*indent + rest) you have set for your project, just as easily as it can draw a line at a column.

The harder problem is that you need a context-aware editor for it to help you with indenting. Most editors are incapable of that by default.

Re:But no, 80-column terminals in 2020 isn't “reasonable” an... by dezgeg on Saturday May 30, 2020 @07:01AM (#23360247)
> unless the coding style also requires you to replace all (leading) sequences of N spaces with with a <TAB>, which is, IMO, quite brain-dead

It is brain-dead, but that is exactly what is required in many styles.