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

The day Return became Enter (2023)

aresluna.org

Post reply on HN
Print view View original

121–130 of 179 posts

Re: The day Return became Enter (2023)

#121

Post by dfox »

rswail wrote: post #78
Animats wrote: post #69

Earlier quoted context omitted.

> It's a damn shame that the control characters for "Field Separator" (FS ASCII 28 decimal) and "Record Separator" (RS ASCII 30 decimal) weren't used instead of TAB and CR/LF. No, it's not. That stuff is left over from 1940s-1950s schemes for polled multidrop teletype machines - multiple stations on one wire, taking turns. The idea was that you punched paper tapes locally and then put them into a reader. When it was…

Why? The use of TTYs for computing interfaces is very different to using them as teletypes on comms links. I thought the control characters for that sort of use were the DC1-4 characters? RS-485 uses polling but my understanding is that the characters for polling usually involve like "FF" (hex) and some sort of device ID. I just read a TTY model 28 manual about the stunt box and I didn't see anything specific about F…

Modern protocols running over RS-485 UART usually use some kind of HDLC-inspired framing scheme with flag characters and byte stuffing.

But still there is a lot of stuff that uses ASCII STX/ETX and then some kind of field separators inside otherwise human readable message. Things like industrial scales, industrial barcode readers and what not usually use something like that as default output format.

Re: The day Return became Enter (2023)

#122

Post by cwmma »

Tangentially related, but there is great paper tracking how the layout of the qwerty keyboard came to be, tracing the slow evolution of it from a two row keyboard with a-m on the top row and z-n on the bottom to what we have today.

https://repository.kulib.kyoto-u.ac.jp/server/api/core/bitst...

Re: The day Return became Enter (2023)

#123

Post by HarHarVeryFunny »

The article illustrates an old 1930's Teletype model 15 with it's separate Carriage Return and Line Feed keys, and claims that these were kept separate (vs a single key/code that performed/represented CR + LF) so that sending the separate LF gave the receiving device enough time to mechanically perform the CR function.

I wonder if this is quite correct?

This Teletype use Baudot code, not ASCII, as reflected by the keyboard including LTRS and FIGS keys. Baudot was only a 5 bit code, so in order to be able to represent/transmit more characters than 5 bits would allow, it used the LTRS (letters) and FIGS (figures) codes to select different character sets (cf ASCII SI & SO), which the receiving system would then need to keep track of.

Apparently the convention was to send the sequence "CR LF LTRS LTRS" to both advance to next line and select the letters character set, with sending the semantically redundant double "LTRS LTRS", giving the receiving teletype enough time to complete the preceding mechanical movements (CR, LF). Given this, it seems that keeping LF distinct from a combined CR+LF operation wasn't needed for timing considerations - one could have just sent as many LTRS as needed.

I wonder was there perhaps a use case for LF without CR with the old Teletypes, or perhaps keeping them separate was just due to the simple mechanical nature of these devices and the different mechanical operations needed to perform CR vs LF ?

Re: The day Return became Enter (2023)

#124

Post by [deleted] »

Findecanor wrote: post #99

> And the IBM PC – and later Microsoft Windows – went with Enter. (Actually, they first chose the ↵ arrow. I'd claim that the article draws its own wrong conclusions. The key was not renamed . On the IBM PC, the key got overloaded with two functions. The IBM PC keyboard was preceded by larger keyboards with the same mechanism, style and font for use with IBM's terminals. Those had two separate keys for ↵ and Enter. T…

[deleted]

Re: The day Return became Enter (2023)

#125

Post by yencabulator »

usr1106 wrote: post #4

Technically the difference is clear. Return is for character based protocols, teletypes, ttys, VT100, ssh and the like. Enter is for IBM 3278 style where a "screenful" or form of inputs is buffered by the terminal and sent as a whole when the user presses enter or send. Fewer interrupts and context switches at the mainframe. Required even its own ssh client. Return key exists, too, and can be part of the buffered dat…

This is hazy memory but I think Return worked like one would expect inside of multiline fields on those IBM terminals. That is, they used both Enter and Return, for different purposes.

Also, if you're ever mystified by SQL's CHAR/VARCHAR handling of trailing whitespace, look into IBM "block-based" terminals and their text input and the conventions match exactly.

Re: The day Return became Enter (2023)

#126

Post by jibal »

Nice history recap, most of which I lived through, but it's missing the Bill Gates/PCDOS botch of using CR and LF as the text line separator, a result of not doing a logical translation of the characters sent by the terminal. UNIX sort of did it right by just using LF, but it would have been better to use NUL as the terminator--then there wouldn't have been the need to strip off LF on input and add it back on output and we wouldn't have the special case, handled differently by numerous programs, of a file ending with a line lacking an LF terminator ... and there wouldn't be the numerous bugs and weird behavior resulting from lines containing NULs.

Re: The day Return became Enter (2023)

#127

Post by jfultz »

Growing up in the 70s, among the things I sought out in our house to play with was an old manual typewriter. It was endlessly fascinating to me. I liked playing with all of the mechanical bits. Trying to jam keys, working the carriage return, scrolling paper through it, pressing the Shift key and looking to see how it moved the entire basket of typebars, overtyping to make new characters, watching how the ribbon advanced with each keystroke and rewinding it by hand, etc. One thing I had forgotten, which was mentioned in this article, was figuring out how to set tab stops, which allowed me to either stutter the carriage across, or make it fly free from one end to the other.

Re: The day Return became Enter (2023)

#128

Post by kps »

Sharlin wrote: post #120
kps wrote: post #115

Earlier quoted context omitted.

Speaking of overloading and Tab, piling on the ‘next field’ function is an endless source of pain.

"Next field" is sort of what tab ulation means. Moving to the next column of a tab ular form.

That was the origin, but for everyday typing of non-tabular work, like letters, it was used for indenting paragraphs and address and signature blocks. And it always moved to the next tab stop to the right on the line. ASCII calls it HT, ‘Horizontal Tabulation’.

Later, some systems, notably IBM's, overloaded this to move to the ‘next’ field on a form, which might be to the left and down the page. So from there MS-DOS/Windows stuck us with a Tab that sometimes moves horizontally within a text field, and sometimes moves to a different field. Just like Return sometimes moves to a new line/paragraph and sometimes submits a form.

Re: The day Return became Enter (2023)

#129

Post by kevindamm »

HarHarVeryFunny wrote: post #123

The article illustrates an old 1930's Teletype model 15 with it's separate Carriage Return and Line Feed keys, and claims that these were kept separate (vs a single key/code that performed/represented CR + LF) so that sending the separate LF gave the receiving device enough time to mechanically perform the CR function. I wonder if this is quite correct? This Teletype use Baudot code, not ASCII, as reflected by the ke…

I don't have additional historical context, but the reason that makes sense to me is that a LF can be repeated multiple times (e.g. for double-spaced lines, or for advancing to the next page) without needing to also issue a CR more than the initial time, since the carriage is already back to the beginning of the line.

Re: The day Return became Enter (2023)

#130

Post by jibal »

Borg3 wrote: post #91
rswail wrote: post #49

It's a damn shame that the control characters for "Field Separator" (FS ASCII 28 decimal) and "Record Separator" (RS ASCII 30 decimal) weren't used instead of TAB and CR/LF. Then the whole CRLF vs CR vs LF for line endings in files would have been totally avoided, with CR returning the print-head/cursor to the left-most position (right-most on R-L languages) and LF literally moving the print-head/cursor down. The dri…

But we do NOT need to setup CRLF translation at all? Who in his sane mind uses CRLF even under windows? All my source codes are in UNIX format (aka LF only) and I use it consistent under Windows, Cygwin and UNIX.. Why make your life harder?

The ability to do that is a recent development. And numerous programming environments still default to adding CRLF and stripping it off when running on Windows, and all the system tools on Windows generate files with CRLF as line terminators so all software needs to deal with them.
Post reply on HN