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);
}
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.
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.