iproute2 and libbpf: vendoring on the small scale

Posted Nov 25, 2020 23:35 UTC (Wed) by marcH (subscriber, #57642)
In reply to: iproute2 and libbpf: vendoring on the small scale by mbunkus
Parent article: iproute2 and libbpf: vendoring on the small scale

> To _me_ having long lines is actually a boon as I'm running terminals that are much wider than 80 characters (as monitors have been way wider than tall for decades now I find wrapping at 80 absolutely unreasonable).

I don't think I've ever seen anyone with a _single_ terminal spanning their entire monitor width, at least not in landscape mode. The monitor width has very little to do with line length, I don't understand how this myth persists.

The 80 characters limit is just a pure convention now: you can't have everyone choosing any random limit and expect text to look good on others' terminal without any waste of screen estate either.

Depending on the programming language and code style (not monitor width), I agree 80 tends to be a bit short but it's very hard to change conventions. 100 characters seems like a decent trade-off but during the never ending "transition" there will be frequent wrapping and 20% waste.

to post comments

iproute2 and libbpf: vendoring on the small scale

Posted Nov 26, 2020 9:36 UTC (Thu) by geert (subscriber, #98403) [Link]

Oh, once in a while I do use a single terminal spanning my entire monitor width. In fact I have used a single terminal spanning two side-by-side 2560x1440 monitors, using a substantially smaller font, to fit a large table in vim ;-) But those are exceptions.

Still, my (multiple) coding windows have 80 columns. When needed, they can be widened temporarily with a keyboard shortcut.

A wider terminal window can be useful for build or serial console output. But coding: 80 columns.

iproute2 and libbpf: vendoring on the small scale

Posted Nov 27, 2020 22:00 UTC (Fri) by nix (subscriber, #2304) [Link]

Ignoring the actual historical contingency reasons for all this (Hollerith cards, etc)... one reason why having a limited length of line may be useful is a truly ancient typographical rule rooted in the biology of vision: in 10-point text at a typical reading distance, any text longer than 65--70 chars or so *under certain other constraints* is too long for easy reading: the eye will tend to lose its visual lock on the line and wander off onto neighbouring lines. It's obvious when this happens to you because it is *incredibly annoying* and you'll get frustrated after only a few lines like this in succession.

But, of course, there are constraints, which make this rule mostly irrelevant for source code. It came from book typesetting and before that quite possibly even handwritten manuscript production, where what is usually produced is text consisting of densely-set paragraphs, more or less rectangles of text with one shorter line at the end, perhaps with a slightly-ragged right edge, but not very ragged because that looks ugly. Source code looks nothing like this: the right edge is extremely ragged, and any lines that stretch the full width are probably standing on their own, not surrounded by text out on the right edge. Lines standing on their own like this are more or less immune from the eye losing track of which line the eye is on: the long line quite literally stands out from the lines around it.

Furthermore, source code is usually indented, and even if it was set as dense paragraphs, the typographical rule runs from the *left edge of the indentation*, not from the left edge of the file (though in books, whole-para indentations are often applied at both edges, expanding both margins, because indented regions are usually quite rare and you want them to stand out). It's perfectly all right, from the perspective of the eye losing track of a line, if the para the line is part of starts 120 chars from the left edge, as long as the *line itself* doesn't have too much text in it.