Live data from Hacker News

But no, 80-column terminals in 2020 isn't “reasonable” any more

lkml.org

151–160 of 330 posts

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#151

Earlier quoted context omitted.

More generally though, there's an argument to be made that line-wrapping should be a thing your editor does as part of the rendering process -- not a thing it encodes into the actual source file. Modern languages come with excellent auto-formatters which can make the code look nice at just about any line length. What we need to do is integrate the auto-formatting into the editor (likely via a language-server) so that…

We could stop storing code as text, just store an AST and let the editor parse it and render it respecting the preference of the user (I think this is a terrible idea, but also got me thinking if there's something interesting there)

> We could stop storing code as text

Why is this terrible? Syntax errors would no longer exist, it would allow editors to work directly with the AST and not text... I think this is a fine idea personally.

Our current editors already try to do this - letting you work with syntax and not text - via smart completions, boilerplate templates, and syntax highlighting. Working with an AST directly is only taking it a step further (and better, it removes the reliance on context-insensitive regex based tooling in the editors).

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#152
post #93
post #6

Many programmers are averse to line wrapping plain text files (especially source code), which has never made much sense to me. There's great support for it in like every editor.

I've recently been getting used to using line wrapping in VSCode (Alt+Z) and it's been working great. I only wish it was a bit more "semantic", similar to running a linter with a specified width rather than just copying the indentation of the previous line, so that e.g. when I need to wrap a line that's a comma separated list (e.g. function parameters) it lines up the list elements in 1 column: def f( a, b, c, d ):

I like it, but then I have adopted a style very similar to that in the last 3 or 4 years: format expressions to approximate their syntax tree, with closing symbols aligned with the line that opened the sub-tree. Essentially, K&R indentation for ALL grouping symbols, not just curly braces. This way, lines are never very long anyway. Well, especially since my JS code has more of a “Ruby, with a dash of Lisp” style than a “Java” style.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#154
post #93

Earlier quoted context omitted.

I've recently been getting used to using line wrapping in VSCode (Alt+Z) and it's been working great. I only wish it was a bit more "semantic", similar to running a linter with a specified width rather than just copying the indentation of the previous line, so that e.g. when I need to wrap a line that's a comma separated list (e.g. function parameters) it lines up the list elements in 1 column: def f( a, b, c, d ):

I like it, but then I have adopted a style very similar to that in the last 3 or 4 years: format expressions to approximate their syntax tree, with closing symbols aligned with the line that opened the sub-tree. Essentially, K&R indentation for ALL grouping symbols, not just curly braces. This way, lines are never very long anyway. Well, especially since my JS code has more of a “Ruby, with a dash of Lisp” style than…

As to vertical size: how much crap are you going to put into one function, anyway? Other than perhaps some local (nested) helper functions.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#155
post #19

Earlier quoted context omitted.

A note on your last sentence. Once I used my Win10 laptop at an interview at Apple. The interviewer saw me drag one window the the side, snap it, and then select another window to fill in the space. He said, wow, Windows is really nice! :)

I use keyboard shortcuts for that: Win+left and Win+right will maximize a window on that half of the screen. That makes it easy to quickly have a terminal or editor on one half and something else (like a browser or PDF) on the other half, using only the keyboard.

Yeah I typically use keyboard shortcuts for them too, good point!

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#156
I’m an 80 cols person, and I admit to be low-key enraged by wide lines. I really like having lots of side-by-side editors and a terminal, and long lines bust that, and I resent what feels like a lack of sensitivity for others’ workflows in many modern tools that generate wide lines.

That said, I try and practice what I preach and let my coworkers who are into wide lines (120, woof) have ‘em. I just run a formatter after I check code out, ez. Everyone should do this, online diffs should default auto format to 80 cols (but configurable), and we should put this debate to rest.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#157

I’m an 80 cols person, and I admit to be low-key enraged by wide lines. I really like having lots of side-by-side editors and a terminal, and long lines bust that, and I resent what feels like a lack of sensitivity for others’ workflows in many modern tools that generate wide lines. That said, I try and practice what I preach and let my coworkers who are into wide lines (120, woof ) have ‘em. I just run a formatter a…

Why should online diffs auto format to 80 cols? Shouldn't that be up to the user?

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#158

I’m an 80 cols person, and I admit to be low-key enraged by wide lines. I really like having lots of side-by-side editors and a terminal, and long lines bust that, and I resent what feels like a lack of sensitivity for others’ workflows in many modern tools that generate wide lines. That said, I try and practice what I preach and let my coworkers who are into wide lines (120, woof ) have ‘em. I just run a formatter a…

Why should online diffs auto format to 80 cols? Shouldn't that be up to the user?

Sorry I ninja edited you. Diffs with wide lines don’t always fit on screens; but if you have a wide monitor, set it to 400 for all I care.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#159

Fwiw, we use 120 columns for Riot/Matrix stuff ( https://github.com/matrix-org/matrix-react-sdk/blob/develop/... ) - 80 is incredibly constraining for JS and JSX. The key metric is to ensure that a typical laptop can show two screens side by side, without any ugly line-wrapping. Also, any wider and you either end up having to scan a wide distance left to right (the same reasons that newspapers use columns to be more…

Nice

120 is also what I've settled on & am used to. But I'd be equally OK, and adjust fine, with anything from 100-120.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#160
If I remember correctly, DEC, Tektronix, Honeywell, Qume and other real terminals moved to 110 characters per line in their later generation terminals.

Coming from the perspective of that era I never understood the obsession with 80 characters per line.

I can honestly say that I have never limited my code through such artifice, ever.

I can give examples of code where artificially breaking things into 80 characters makes an absolute mess out of things. Complex table-driven state machine lookup tables and FPGA I/O definitions come to mind, among others.

Post reply on HN