Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lkml.org

Post reply on HN
Print view View original

101–110 of 330 posts

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

#101

Post by wallacoloo »

saagarjha wrote: post #32
stickfigure wrote: post #21

The problem here is that our editors aren't smart enough to wrap code appropriately. Word processors know to wrap lines on word boundaries; a smart code editor should be able to wrap lines and indent parameters in a human-pleasing way as you drag a window wide or narrow.

I think most editors these days do a pretty decent job? It's not perfect, of course, but 99% of the time it's fairly readable.

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 it can adjust to the width of the editor dynamically instead of running it directly on the files at some width that's forced to be the same for every user of the codebase in every setting.

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

#102

Post by mekkkkkk »

u801e wrote: post #57
saagarjha wrote: post #27

I'm a big fan of softwrapping. Not because it's inherently prettier or something, but because the results are consistently better on more platforms because they can softwrap at what you've set the column width to be and not some arbitrary number someone thought was a good idea. (I have a similar argument for using tabs, but I digress.)

This is what Linus has said in the past regarding soft-wrapping: https://github.com/torvalds/linux/pull/17#issuecomment-56611...

Ironic that his reply is almost unreadable on mobile because of his hard wrapping. Intentional?

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

#103

Post by ken »

u801e wrote: post #33
winrid wrote: post #12

This!! At people are insisting we use a max of 80 columns for the linter. It's a huge pain compared to 100 or 130 columns and doesn't help readability. Everytime someone tries to argue for it I want to suggest we swap their Mac for a Commodore 64...

Well, the C64 had a 40 column display width for the BASIC interpreter, but I think it was possible to have statements that wrapped and could go up to 80 characters (I may be wrong about that though).

Up to 79 characters, including the line number.

Interestingly, this was basically (ha) an editor limitation, not a language one. You could use 2-letter abbreviations for the language's reserved words to cram more code into the same space. The programs were stored (IIRC) in tokenized form.

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

#104

Post by u801e »

mekkkkkk wrote: post #102
u801e wrote: post #57

Earlier quoted context omitted.

This is what Linus has said in the past regarding soft-wrapping: https://github.com/torvalds/linux/pull/17#issuecomment-56611...

Ironic that his reply is almost unreadable on mobile because of his hard wrapping. Intentional?

Github provides an email to Github comment gateway. So he was composing his replies in his email client.

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

#105

Post by data_ders »

vincent-manis wrote: post #92

I long ago concluded that arguments over line width, indentation, etc. are a waste of time. If I were submitting a kernel patch, I'd follow the Linux standard without complaint, regardless of my preferences. That said, the best argument on line length is “the magic number 7, plus or minus 2”, our limits on short term memory. I like to be able to comprehend a line of code (or of text) in one glance, which seems to me…

ooo i love idea of tokens per line idea. do you mean distinct words per line? or conceptual objects you have to juggle in your head?

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

#106

Post by colechristensen »

Normal_gaussian wrote: post #71
colechristensen wrote: post #24

Earlier quoted context omitted.

Splitting one line into many because of character limits can also make an action overly verbose or mentally challenging. In some cases, unreasonable gymnastics needs to be done to get 80 character lines, turning good variable and function names into shorter worse ones or adding functions just to hide characters.

most languages support simply adding "visual" newlines in the middle of a "logical" line; I tend to do this to improve readability - could this be done to avoid your long lines?

Sometimes, but not always.

I often do it too to improve readability, but it doesn't always actually improve readability. Sometimes it takes something which makes logical sense to have in one line and arbitrarily breaks it up in awkward spots over several lines.

If you squish code into 80 characters wide, you lose vertical density, making a set of actions more difficult to understand by separating steps.

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

#107

Post by cgriswald »

gnarbarian wrote: post #37
shockinglytrue wrote: post #13

Typical ill-considered comment from Linus, and surprising for someone getting on his years. Column width is an accessibility issue . I'm barely in my mid 30s and the average font size has been steadily creeping, maybe 1.5 pts per 5 years. I could tolerate 132 column files today, but by the time I'm 50 there is no way this will work, regardless of screen size

Buy a bigger monitor. Or get glasses. I'm 38, rocking a 43" 4k monitor. There's so much room. Scale things up or down to your comfort level. It's a pleasure if you use an editor like atom.

I generally agree. My allergies really mess with my near vision, which is otherwise very good. My needs change. Should everyone else have to change how they do things to meet my changing needs? We have the technology to make any line length equally accessible to everyone.

We should be focusing instead on the contextual and cognitive pros and cons of various line lengths.

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

#108

Post by delaaxe »

Arathorn wrote: post #48

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…

I've found 120 to be the sweet spot - it either fills a laptop screen entirely or allows 2 open editors on a wide screen.

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

#109

Post by pkilgore »

vjeux wrote: post #52

It's ironic that he's wrapping the text of this email at 80 columns rather than letting the email reader do the wrapping based on the width.

> Word-wrapping is a property of the text. And the tool you use to visualize things cannot know. End result: you do word-wrapping at the only stage where you can do it, namely when writing it. Not when showing it.[1]

- Linus Torvolds

[1] https://github.com/torvalds/linux/pull/17#issuecomment-56611...

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

#110

Post by kstrauser »

thedirt0115 wrote: post #43
kstrauser wrote: post #30

Earlier quoted context omitted.

The #3 productivity app on the Mac App Store is a $2 app that enables this on Apples: https://apps.apple.com/us/app/magnet/id441258766?mt=12

Hammerspoon can do this (and way more!) for free :) https://www.hammerspoon.org/go/#winresize

Oh, nice! I really prefer the window dragging method, though, and it doesn't seem like Hammerspoon supports that.
Post reply on HN