On Thu, Nov 5, 2020 at 8:41 PM Larry McVoy <lm(a)mcvoy.com> wrote: I click but I mostly live in Aw, c'mon. You're going to tell us that the number of punch holes that IBM could fit on a punch card in 1928 that was exactly the size of the dollar bill used in the U.S. from 1862 to 1923 so that it could be stored in a mechanical cash register is miraculously the Right Thing when it comes to reading monospaced text on a screen? I think that's asking a bit much of ol' man Coincidence. ↓↓ 80-column .sig ↓↓ John Cowan http://vrici.lojban.org/~cowan cowan(a)ccil.org MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS

https://github.com/golang/go/commit/a625b919163e76c391f2865d1f956c0f16d90f83

Will, I do still the same thing, but the reason for 72 for email being that way is still card-based. In FORTRAN the first column defines if the card is new (a blank), a comment (a capital C), no zero a 'continuation' of the last card. But column 73-80 were 'special' and used to store sequence #s (this was handy when you dropped your card deck, card sorters could put it back into canonical order). So characters in those columns were typically ignored. Thus when "Model 28 ASR" (a.k.a. ASR-28) created it had 72 columns. It's interesting that when its follow on the Model 33 was created, it actually had 74, but most SW configured it to 72 [search for a manual on bit savers or the like if you want the details]. IIRC, the original DEC 'Glass TTY' - the VT-05 was 72, but later terminals like the VT-52 were 80 columns, as was the ADM 3A. The one thing I will give the 'tyranny of 80-columns" is when I look at code it starts to break that line size by a lot, I often think that is a bell-weather of something that needs to be rewritten and simplified, and/or the abstraction might not be right. Like, most/many rules there >>are<< often break exceptions, but when I do look code with really long lines, I admit I am suspect. Clem On Fri, Nov 6, 2020 at 8:21 AM Will Senn &lt;will.senn(a)gmail.com&gt; wrote:

Typewriters. In typesetting, especially when doing right-margin justification, we have "stretchy spaces" between words. The space after end-of- sentence punctuation marks is supposed to be about 50% larger than the width of the between-words spaces, and if the word spaces get stretched, so should the end-of-sentence space. Note that this is all in the variable-pitch font world. Since typewriters are fixed-pitch, the way to emulate the 1.5-space-wide gap is to expand it to 2. Chris

Greg 'groggy' Lehey wrote in &lt;20201106225422.GD99027(a)eureka.lemis.com&gt;: |On Friday, 6 November 2020 at 7:46:57 -0800, Chris Torek wrote: |>> I use single spaces between sentences, but my ancestors |>> used 2... who knows why? :). |> |> Typewriters. |> |> In typesetting, especially when doing right-margin justification, |> we have "stretchy spaces" between words. The space after end-of- |> sentence punctuation marks is supposed to be about 50% larger than |> the width of the between-words spaces, and if the word spaces get |> stretched, so should the end-of-sentence space. | |FWIW, this is the US convention. Other countries have different |conventions. My Ausinfo style manual states | | There is no need to increase the amount of punctuation ... at the | end of a sentence. | |I believe that this also holds for Germany. I'm not sure that the UK |didn't have different rules again. Yes, the DUDEN of Germany says for typewriters that the punctuation characters period, comma, semicolon, colon, question- and exclamation mark are added without separating whitespace. The next word follows after a space ("Leerschritt", "void step"). However, typewriters often place(d) those characters left in a cell, so that the visual appearance is accordingly. In novels around 66 characters is the recommendation i seem to recall. I have that in mails, 72 in other text modes, and 79 for everything else. (The latter lead to lots of ugly code once i used tabulators, but different tabulator spacing would have resulted in different look in $PAGER and $VISUAL, so ...) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

On Sat, Nov 07, 2020 at 09:31:08AM +1100, Dave Horsfall wrote: Yes all, we've drifted out of Unix and into old fart territory, so please move over to coff(a)tuhs.org for future replies! Thanks, Warren

On Fri, Nov 06, 2020 at 05:37:25PM +1100, Greg 'groggy' Lehey wrote: Exactly this. I'm a very fast reader, easily 2-3x the average. I read by running my eyes down the middle of the page and get the left and right from peripheral vision. It's super fast but it doesn't work when you get much bigger than 80 columns. Even if you read normally, the wider it is, the more back and forth your eyes do so less is more. It's also why I'm fine with smaller screens, I tried the giant apple displays and found that those required head movement along with eye movement. I'm lazy.

Yes -- this is the (or at least "an") argument for two-column text on wide (8.5x11 or A4, or larger) paper pages. I am too, but I still use a big screen: I just fit a lot of smaller windows in it. I'd like to have a literal wall screen, especially if I'm in an interior, windowless (as in physical glass windows) room, so that part of the wall could be a "window" showing a view "outside" (real time, or the ocean, or whatever) and other parts of the wall could be the text I'm working on/with, etc. (But I'll make do with these 27" 4k displays. :-) ) Chris

Larry McVoy writes: We're getting into religion again here, and I've never found that to be a sound basis for policy. I'm going to quote liberally here from a screed that I wrote (but have not published) when trying to understand parts of the linux kernel. I've always been willing to spend buckets of money on the monitors because to me that's an area where bigger and higher resolution is always better. I've been using 132 column terminal windows since sometime in the 90s when I got myself a monster 24" Trinitron monitor from Sun. I seem to recall that it listed for $3,300, thanks to the unnamed person who got me the employee discount :-) I tried going to 160 columns but that was too wide for the monitors that people I worked with had. I hated Shakespeare in high school. One of the big reasons was that I felt that he made up a word whenever he didn't have a good one available. The flipping back and forth to the list of definitions completely interrupted the cadence of reading. The insistence on short line lengths in coding standards and the contortions that people go through to meet them has the same effect for me. I've coined the phrase "mental locality of reference" to describe this; at least I think that I'm the first one to use it. Short lines and modern coding styles ask the human brain to contort itself in ways that we are loath to ask hardware to do. As near as I can tell, the belief that people do best with line lengths between 50 and 75 characters long is the result of people repeating "wisdom" that they heard from someone else that orginates from what I consider to be a misreading of Emil Ruder's book "Typographie: A Manual of Design". While Ruder does make this statement about line length, it's in the context of normal typography. It does not even remotely consider computer code where long lines are long mainly due to leading whitespace. To the best of my knowledge nobody has studied this - does the line length when counting begin at the first column or the first non-whitespace character? While readers might "lose focus" part of the way through long lines, that has to be balanced against the loss of focus that comes from 'mental carriage-returns" when text is too narrow and broken across several lines. Again, not studied as far as I know. The linux coding standard makes the unsubstantiated claim that having more than three levels of indent is a problem. And it's really hard to understand, because on one hand, it says that you "should fix your program", and then says that "nesting functions too deep" is a problem. Sounds like a catch-22 to me; how are you going to minimize indent if you can't nest functions? I'm guessing that someone typed this without reading what they wrote and really meant "statements", not "functions". We're back to the mental locality-of-reference thing that was mentioned earlier. I'd much rather have a few more levels of indent and longer lines than have to go chasing gratuitous function calls. Think about every diversion from the stuff in front of you as a cache miss. When I look at the linux kernel code, I see incredibly bad contortions made in attempts to meet the coding style. I also observed that the code only loosely follows its coding style. How are people limiting their code to three indent levels? By including dozens of header files that contain static inline functions. Gak! I feel that style rules should be observed in some sort of priority order, and mental locality of reference, which isn't in anybody's rules but mine, is at the top of the list. I could go on, but hopefully I've made my point. Jon

John Cowan writes: As I said in my original post, we're getting into religion here. So we have different views on monitors; I am contemplating replacing my 32" UHD monitor with a 70" UHD TV. Why? Because I can keep everything on my screen the same which will make everything bigger so I can put the monitor farther away getting me out of my farsighted zone and into my 20-20 range which would eliminate the need for glasses. Not gonna rathole on the Shakespeare analogy - maybe I'm wrong but it's not relevant to the point that I was making. The books that we were given in high school didn't have pop-up translations or footnotes. In case I wasn't clear in my original posting, the topic was mental locality of reference issues as related to terminal size and coding style. Jon

On Fri, Nov 06, 2020 at 11:12:23PM +0100, Andy Kosela wrote: Yeah, I wasn't a fan of going wider. I'm bucking the old school trend and typing on an 80x44 terminal which is as tall as I can go on my X1 Carbon. It's big enough. For me, taller is more useful than wider, provided I can get about 162 columns so I can do side by side diffs. More than that doesn't do much for me. But I'm pretty old school, I write in C, I debug a lot with printf and asserts, I'm kind of a dinosaur. In the last year or so I reconnected with Kirk and Eric and much to my surprise, and pleasure, I found that Eric and I see things very similarly, I'd be happy to work with/for that guy, we really agree. One thing I will say about big monitors is they are great for photos. I do a lot of digital photography and have no desire to go back to black & white or CRT terminals.

A lot of industrial design is based on inheritance. The nitrocellulose filmstock was nominal 40mm, after cutting and sprockets it was 35. cut it in half you have 16mm single sprocket. Original manufacture was 80 wide cut in half so undo that and you get 70mm. run the film sideways, you now have 700 high for IMAX dimensions. Why was nitrocellulose film stock coming in 80mm wide strips? Ask somebody who knows what George Eastman was doing at the time... My guess is the tank emitted 100mm but the edges were crinkly, and 80mm was what he got after slicing ragged margins. The rest is inheritance down the stack working on 1/2 and 1/4 sizing consequences. IBM was business machines. tabulators. The sheet stock it used for things in business was defined by what it could source coming in, reliably. The US census used hollerith cards, this is probably why the fed reserve used hollerith cards. (My G/F got a 1978 tax cheque refund from a camp school in the midwest on a hollerith-card-cheque, the last time I saw one in anger outside of the computer labs where we were still using them in anger, very anger) the Banks first atm's used card stock for receipts. they were mini-hollerith. I imagine because they understood how to do alignment from a cut corner, and had machinery which worked. I was told that fmt/72 is a post-hoc rationalisation to allow for 4-5 levels of indentation in >>>quoting. I think this is a post-hoc rationalisation of a prompter hoc reality. If you go back into teletype deep history, I bet you find 40/60/72 was coming out of some combination of fixed-width typeface, mechanics, and paper stock sizes available in the supply chain. (Mike Lesk told me the TBL offset in the T/ROFF box drawing was because of a highly specific throwback effect in the printer at Bell. The code was adjusted to deal with this, and the rest of us had to wear the top and bottom lines being misplaced without a patch to the code. This kind of thing, its classic "because we could, and because it works" decision logic) On Sat, Nov 7, 2020 at 10:17 AM Dave Horsfall &lt;dave(a)horsfall.org&gt; wrote:

On Fri, Nov 06, 2020 at 12:05:38PM -0500, Paul Winalski wrote: That's hilarious, I missed that joke when watching as a kid.

I’m going to chime in on pro-80-columns here, because with the text a comfortable size to read (although this is getting less true as my eyes age), I can read an entire 80-column line without having to sweep my eyes back and forth. I can’t, and never could, do that at 132. As a consequence, I read much, much faster with 80-column-ish text blocks. I also think there is something to the “UNIX is verbal” and “UNIX nerds tend to be polyglots often with a surprising amount of liberal arts background of one kind or another,” argument. That may, however, merely be confirmation bias. Adam

On Fri, Nov 6, 2020 at 12:26 PM Stephen Clark &lt;sclark46(a)earthlink.net&gt; wrote: In fact the Labs had the more recent Model 37, which did lower case, unlike the 33. Consequently, Unix was (I think) the first case-sensitive operating system. However, it had to work on 33s as well; if you tried to log in using an uppercase username, login would turn on the IUCLC and OLCUC bits of /dev/tty, and if you needed an uppercase letter you had to escape it (I think with \), which the tty driver processed. Thanks to everyone for filling in all the gaps in the chain from dollar bills to 80-column terminal windows that I had left implicit. To clarify my position, what I am opposed to is not the use of 80-column windows for *reading* email. I'm not happy with what happens to text that is hard-wrapped at 80 columns when displayed in a narrower window, as often happens to me now that I use larger fonts than I used to. The text/format-flowed MIME type was supposed to help with this problem, but never really caught on. "Well, I'm back." --Sam John Cowan &lt;cowan(a)ccil.org&gt;