> 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.
The ↵ symbol was the Return symbol signifying the Return function.
The textual legend "Enter" signified the Enter function, for data entry.
Some early Model F XT keyboards did not have stabilised keys so the touch-area had to be 1×1 with room only for ↵.
From the Mode F AT (large backwards-L key) forwards however, the key did have both legends: ↵ and Enter. From there on, "Enter" is mostly just what IBM PC users called it.
There are other common misconceptions about key legends. For example that ↹ would mean Tab, when it is two symbols: ⇥ for Tab and ⇤ for Back-Tab. Back-tab is on the top because it is activated with Shift. (And again, some IBM terminal keyboards had separate Tab and Back-Tab keys. Apple keyboards have only the ⇥ symbol, BTW.)
Apple keyboards don't use the ⇥ symbol anymore, it's just labeled "tab" now (and the labels are lowercase). At least on a US keyboard, possibly it's different for others.
I still call this key “omppu” in Finnish (meaning “apple”) because that’s what everyone called it in the 1990s when it still had the “open apple” legend.
And young people look at me like I’m crazy when I tell them to press “omppu Z”… But it’s a hard habit to break. I don’t even know what the official name of the key is in Finnish.
Normally that's fine, because the tab stop points to the next field. That's the whole point of tab stops― you place them at the beginning of fields on a forms. (Yeah, you also need to be on the right line, so a single key press rarely gets you there, but we were working with purely mechanical controls.)
Where it goes off the rails is when we embed a user interface inside another user interface. That's not a problem specific to the tabulator, but also with all novigation functions, like home, forward, and back.
I rarely use web-based email interfaces, but when I do, I accidentally send half-written email messages, because I'm trying to use a block quote or something similarly indented. It's especially bad when the next field is the 'Send' button, and pressing the spacebar sends the message.
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.
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 drivers for the particular terminal could have translated as required, and we would not need (in 2025!) to be specifying to git and elsewhere what to convert line endings to/from.
I know that back in the days of literal TTYs (ASR-33) where I cut my teeth, the BEL/BS/SP/CR/LF/FF etc characters were literally controlling a print head, but even then it didn't make much sense that we didn't have internal representation of what was needed (field separator, group separator, record separator) that was translated when doing actual I/O to a physical device.
> 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 your station's turn, the central machine would send a polling sequence of a few characters, the selected reader would start up, read one message into the upstream system, then stop. In the other direction, the central station could send a turn-on code to any machine, print a message, then turn it off. Only one machine at a time could run. Those control characters were the delimiters for that process. All of this was mechanical, done by a unit called the "stunt box", which you can look up if really bored.
RS-485 is a descendant of that technology, still used in some industrial control systems.
(I used to restore antique Teletypes for fun, and had a functional Telegraph Office at steampunk conventions for about seven years.)
> I just read a TTY model 28 manual about the stunt box and I didn't see anything specific about FS/GS/RS there.
The Model 28 was a 5-bit Baudot (ITA2 code) machine with a stunt box. The Model 35, an ASCII machine, had a similar system, with different coding.[1]
The term "Selective calling" replaced "stunt box".
ASCII-67 is modern ASCII, but there was previously ASCII-63.[2] That keyboard has special keys for selective calling. WRU, RU, EOT, EOA, TAPE, ~TAPE, etc. Codes didn't become standardized industry-wide until ASCII-67. Before that, there were lots of variations.
Here's a popular view of the process in the Baudot era.[3] That big switching center is essentially Sendmail built from of relays and paper tape equipment. It was called "Plan 55-A".[4]
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.
Editing a file like that with a text editor is a right pain. Inserting these characters isn't all that straight-forward, and everything will be on a single line. In theory RS could be treated as a newline, which will only add to the line ending confusion.
I think this is one of those things that sounds kind of nice in principle, but where the real-world practicalities just don't work out.
The file editing is an I/O issue, not a character issue.
The I/O drivers could translate as necessary, that's the point of using an explicit character to mean "new line" as opposed to either "carriage return" or "line feed".
Effectively moving away from explicit carriage and paper controls to a character that was explicitly internal to mean to generate whatever carriage/paper controls were needed on output/editing etc.
RS separates logical "lines" or there is "Group Separator", but for internal line separators in a multi-line text field, the CR and LF characters could be used, because they have "standard" meanings for text:
CR: move next character position to position 1 horizontally
LF: move next character position to vertically below current character position, potentially inserting SP characters.
So a combination of CR/LF, or LF/CR would have the effect of "New Line".
Comma Separated files would likely exist because they're human readable, whereas FS/GS/RS/CR/LF are not visible.
There is "pipe delimited" which used "|" (ASCII 124 decimal) to separate fields, which actually makes way more sense, because that character is rarely used in normal text.
It's also a good separator when a human is reading the file.
They could be made visible. On MSDOS it was common to have editors show an arrow as ESC or EOF, respectively pointing left or right. A lone CR was a musical note.
I am not sure whether RS could have replaced LF or CR+LF in this kind of free-format database; overloading record and line separators makes sense. But if FS-separated fields were a thing, people on MSDOS would have been used to seeing ⌙ as a field separator and likewise for other OSes.
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?
I think the issue is that people don't make their own lives harder, but sometimes they make the lives of other people harder (often unintentionally). In my experience, the CRLF files I run into tend to come from developers who are only working in Windows and either aren't aware of the issue or don't particularly care to do anything about it. It isn't something I run into often when cloning a git repo, but having recently started dabbling in the world of mod development for games, there's a lot of stuff out there that seemingly has never been touched by someone who's used Linux before. To be clear, I don't blame anyone for this, since people working on things for free in their spare time shouldn't have to worry about anything other than what interests them, but it's a bit amusing to me that I sometimes have less to configure to run an .exe on Linux than I do to start editing the source for it in a way that makes it easy for me to merge any new changes that happen upstream.
> I sometimes have less to configure to run an .exe on Linux than I do to start editing the source for it in a way that makes it easy for me to merge any new changes that happen upstream.
Are you doing anything more than calling dos2unix?
> 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?
Why would you use LF if the focus of the application that you develop is Windows? You make the life harder for these users. :-)
Seriously: your argument typically comes from developers who consider GNU/Linux as a first-class citizen as a development or deployment platform, and Windows only as a second-class citizen (assuming that a Windows port actually exists).
I can accept an argument like "I, as a developer, don't care about Windows and its users, so all my source code is in UNIX format." This is a conscious, though quite political decision.
But an argument like "not using LF makes lifes harder" without a relativization on which premises this claim is build (such as "GNU/Linux and macOS users are much more important for as, and if there exist any users or developers who use Windows, we consider them to be undesired, because they make everybody's lifes harder") is intellectual ignorance.
Using LF on Windows is really not difficult. Any text editor actually worth using supports both types of line endings - even Notepad has handled this correctly for years now, from what I remember. I've never been caused any inconvenience as a Windows user by files with LF endings. I never use CRLF if I can avoid it; I only will if working on a codebase that already uses it throughout.
Oh, its simple. There are many many flavors of UNIX and only one Windows. Hence, I see LF as more portable way to store source code, thats why it is prefered.
Additionally, im heavy CLI user so again, more geared toward UNIX systems.
If you develop on windows and only for windows, use CRLF all the way. Just do NOT forget to set .gitattributed correctly, and you are set.
> There are many many flavors of UNIX and only one Windows.
With ReactOS, there even exists a flavor that is not developed by Microsoft. If you consider Wine and its derivates as an implementation of the WinAPI, you have one additional (or multiple if you consider their derivates) implementation of the WinAPI.
Even if you only consider the flavours of Microsoft Windows that are full operating systems, you immediately get multiple ones:
- the discontinued Win 9x series
- the discontinued Windows CE, Windows Embedded CE, Windows Embedded Compact, Windows Mobile, Windows Pocket series (technically quite different from both Windows 9x and Windows NT)
- Lots of variants (indirectly) derived from Windows NT:
* Windows (desktop OS)
* Windows Server
* Windows IoT (I would claim that at least for the Windows 10 IoT Core version, the user experience is quite different from both desktop and server Windows)
* Windows PE [1]
* Further discontinued variants such as Windows Phone
I fully agree, but we're talking history here, before Unix existed.
The confusion about "LF" (Unix) vs "CR" (Apple) vs "CR/LF" (MS/DOS & Windows) is because we didn't have an explicit "Line End" character in 7-bit ASCII.
There was "EOT" (Ctrl-D/ASCII 4/EOF in Unix) , "ETX" (Ctrl-C/ASCII 3), and other characters that were used to mean other I/O, including ones that didn't match the ASCII definition like Ctrl-S/Ctrl-Q to stop/start I/O, and Ctrl-Z to mean EOF (MS/DOS & Windows).
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.
The language runtime will insert/remove CR for you if you open the file in text mode on Windows. You'd be surprised how much stuff cygwin itself actually does for you. If your code isn't too Linux specific try building it under mingw instead and you can see what's actually going on.
Cygwin does NOTHING under the hood, because I asked it to do nothing. I am aware of text mode of open() under Windows/Mingw. Im also aware of possibility to do CRLF <-> LF translation under cygwin. I never liked it, and I went to LF only quickly. Hence, I use it everywhere and live is easier :)
Really interesting to read. I have used a lot of strange systems in my time. In the military signals group I have worked a lot with teletypewriter systems and the like - also the civilian telex system and the Aeronautical Fixed Telecommunication Network: https://en.wikipedia.org/wiki/Aeronautical_Fixed_Telecommuni...
One thing the article doesn't mention is that some of the old teletypewriters were so slow that you could not be guaranteed that you would get the carriage to the start of the line by using only one Enter character, so it was mandatory to use two.
This meant that all linefeeds consisted of the following characters: CR CR LF (two carriage returns followed by one linefeed). Even in the time where most of the equipment were modern and didn't really need this, you couldn't know if somebody somewhere still had an old teletype running. So this was mandatory and part of the standard.
On mainframes there is also a distinction between Return and Enter. As far as I remember there was a soft return, which only moved the cursor down. And there was a hard return, which acted as Send - thereby transmitting your screen to the mainframe.
Something similar can be used on modern computers. Here is an example in Excel: If you edit a cell (with F2) you can end the edit by using Enter. But if you have enabled to wrap text you can use Alt+Enter to just input a linefeed without exiting the editor.
Enter and Numpad Enter are still distinct in QMK, and possibly some video game keybinds (just as numrow and numpad numbers can be recognized separately). Comparable to the left/right versions of ctrl, alt, super, and shift, I suppose. Fuctionally equivalent usually but can be differentiated, like a hypervisor using right alt to unfocus input.
I wonder if the labels on your linked keyboard really mean much. It could be like how Apple calls their backspace key delete, and has their own names for some of the modifiers.
Back in the last century, Mathematica was like this as well. On Macs, "return" wouldn't run the command you entered, you had to hit "enter" from the numpad. Shift-return may have worked as well, but it's been so long I couldn't say for sure.
What a wonderful essay. I learned to type on a manual Underwood typewriter with a carriage return lever. I don't miss it, but there was something so satisfying about moving that lever and feeling the whole carriage move. It meant that I had typed another line, and had made progress. The thing I truly don't miss was not being able to afford a new ribbon, and having to move back over every character and type it again to make sure that it showed up because the ribbon was so dry. Or not being able to undo mistakes.
The "ding" is a bell that is mechanically activated when the carriage gets close to the end of the writeable area (in many typewriters, this is a moveable stop to account for variable paper width).
So when one types, the bell alerts the typist to the need to return the carriage; typically you get quite a few characters after the bell, either to finish your word, or hyphenate.
Which makes it ding-slide rather than slide-ding :)
This was also an option on many "Glass TTY" terminals - it was called the margin bell - and even some modern terminal emulators still have that option. The exact semantics vary, but it's usually triggered when entering content around 8 characters from the right margin.
I remember back in the early 90's installing an extension on every Mac in the school computer lab that made typewriter sounds on every keypress, including that "zzzzzzipDING!" sound when hitting return (or was it "DINGzzzzip"?)
It was hilarious for a few minutes, then got old really quick, so it didn't last the day. The Oscar extension stuck around for months though ("I love it because it's trash!"). Computers were just so much fun back then...
I remember being mildly intrigued as a kid when I started seeing PCs with the Enter key where my C64 had Return.
It's ironic that, though we haven't seen a Return key for a long time, the down-left arrow symbol still used on many keyboards represents the motion of a carriage return. I guess there's no other symbol that would convey the meaning of Enter as well.
Wow, throwback to running MacScheme (I think) on the university's Macs in a computer lab in the mid-90s. It interpreted main keyboard Return differently from numpad Enter, which to me (coming from the Amiga) was very confusing.
If I recall correctly, only Return caused an evaluation attempt, while Enter merely added a line break for readability.
That would be incredibly handy for chat bots - the number of times I’ve accidentally hit return and then has to interrupt the bot so I can finish typing…
Good old daringfireball! Ah, of course it makes sense, things akin to the shift+enter for adding new lines in messages without executing them or vice versa. I should’ve known.
The first programmable device I owned was an HP scientific calculator, which had a big Enter key, the only key spanning the space of two regular keys on the device. A friend opined that you could tell that it was a real computer and not just a calculator by the presence of that key. It wasn’t true though, the Enter key was there for the HP’s RPN operation and wasn’t otherwise relevant to its programmability.
I remember back in the day I had a demo disc where one of the installers (I think it was Theme Park?) had a prompt of "Press return to quit, press enter to continue". And that confused single-digit-years me for a surprising amount of time, as there wasn't, to my mind, a real difference between the two keys.
Even then I assume it was really a troll as much as anything else.
My experience is with IBM AT and OS 2 which had a Return and a numpad with an Enter. The AT and Model M keyboard at least were part of a very popular and influential generation or two of "PC".
I was a backer of the "Shift Happens" kickstarter and can confirm it has given me hours of enjoyment thinking about the way humans interact with their creations. This article is just a small fraction of the weirdness you find in keyboards over time. And I wonder if there's enough interest and content for narratives focused on joysticks or mice/trackballs/trackpads/nubs or game controllers or ...
I was a little surprised the Space Cadet keyboard didn't come up, but I guess this is an article about the return/enter key and not various modifier keys.
About 5 years ago I was teaching a college class how to format something and I said, "then you just hit return" and most of the class didn't know what "return" was.
Subtle clickbait. Promising "the day return became enter" to entice. It can be narrowed down to a single day, or at least close enough to a single event that way can pick an effective day? Was it a single product release? A single software release? I'll read the article to find out.
> There was no day, no single event when Return became Enter
Oh, never mind then...
Could've just titled it "The history of how Return became Enter" or "How Return became Enter"
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 data record.
In practice the enter term leaked into the character-based world.
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.
And of course ASCII separates them, with LF (linefeed, sometimes called newline) and CR (carriage return, or just return) being two separate characters. Windows (and probably some other) text file conventions used CR+LF to end a line, while unix conventions used just LF (hence the alternate name of "newline").
In line printers, a line feed moves the paper forward one line. A carriage return moves the print head back to the start of a line. You can do interesting things by making them separate commands, like bold text (overstrike) or underlining, so they were independent commands for talking to a line printer.
ASCII standardized on a character set containing control codes for line printers, so it included CR and LF separately. It's a bit weird that some terminals changed the semantics of those control codes, but I guess things never stay static in time.
Line printers (also "chain printers" from IBM) used "form feed" to move the paper to the next "form", which for the most part was moving the tractor fed paper to the line after the page perforations.
The printers either kept track of the number of lines printed "so far", or, in the case of a chain printer, there was a literal chain (similar to an engine timing belt) that had a particular location that was supposed to be aligned with the paper perforation.
Standard tractor feed paper had a printable area that was 132 monospaced characters wide (13.2") and 11" high. Tractor feed paper had the holes at a standard distance apart vertically and a standard margin to allow for the tractor holes and an area before printing, so that the paper could also have vertical perforations to remove the tractor feed paper after printing.
Teletypes were 72 characters wide and 0.1" line height and used continuous paper rolls.
I liked this article a lot because I’ve spent way too much time thinking about things like this, thanks to my mechanical keyboard and keycap hobby.
That said, it misses a key ancestor: the original Macintosh Keyboard (M0110). It had a Return key AND an Enter key in the bottom row, to the right of the spacebar and next to the Option key.
There was Command key on the left only, which seems to mark the evolution from the “Open Apple” and “Closed Apple” keys. If I recall correctly, Return was intended for typing, while Enter was used for GUI interaction, but I’m not entirely sure.
Even into the 2000s, laptops were still figuring things out. I had a 12-inch PowerBook G4 with two keys labeled “Enter”:
- One accessible via Fn + Return
- One as its own key in the bottom row, next to the right Command key
This layout meant it only had one Option key. It also featured a lockable numpad layer, so having a standalone Enter key made less sense to me. Unless it was meant for spreadsheet number crunchers? Or there was still that typing/GUI distinction in Mac OS 9 somewhere?
To me, "return" implies a "go back" action (like "backspace"), which is the opposite of "enter", so naming the key the latter makes more sense. Plenty of TUIs used the arrow keys, Backspace, and Enter for navigation.
Also, the text is nicely readable but none of the images are viewable.
It was one of the things I found amusing my first time using OS X after growing up on Windows. Enter would “enter” a folder or execute a program, while Return in Finder starts renaming the file.
On Windows you can rename with F2, and on macOS, Command-Down will work like enter does on Windows (I think of it like going down a directory, since up does the opposite, though it also will launch a file).
You open files and directories far more often than you rename them, so F2 makes sense for rename but Enter / Return doesn't. It was clearly an afterthought as Macs were always meant to be used with a mouse.
As I understand it, "return" is a shorthand for "carriage return" - as on typewriters, going to a new line meant returning the carriage to its original (start of line) position.
Carriage return moved the paper (on typewriters before the IBM Ball) and moved the print head (the "ball" on an IBM typewriter, or the actual print head on TTYs and DECWriter equivalents) back to column 0.
Line Feed moved the paper up one line, Form Feed moved the paper up by a "form length" or, in the case of chain printers, to the particular position on the chain that was synchronized with the perforations on the paper itself.
The carriage return physical device on the typewriter combined moving the carriage (which could be done by hand) and the rolling of the paper up one line (which could also be done by hand) into one convenient motion.
> Carriage return moved the paper (on typewriters before the IBM Ball) and moved the print head (the "ball" on an IBM typewriter, or the actual print head on TTYs and DECWriter equivalents) back to column 0.
Carriage return always returned the carriage to the far right. Neither the print ball (if there was one), the printwheel, nor the typebars moved. Linefeed rotated the platen.
It's true the carriage return lever operated both the carriage and the platen. Manually operated with the left hand and pushed one level deep it would release the carriage lock and let you return the carriage to the right. Pushed a second level deep it would rotate the platen one, one and a half, or two lines depending on the setting.
> Neither the print ball (if there was one), the printwheel, nor the typebars moved.
Certainly the head moved on most if not all ball/cylinder/wheel devices. Look at the Selectrics, Teletype 33, the Diablo/Xerox/Qume terminals, as common examples.
I have never seen a Selectric in which the ball moved instead of the carriage. I can't imagine how complicated the mechanics would be for that and how often it would jam, break, or malfunction. Certainly not something a company such as IBM would make their reputation on. I used many Selectrics in my time.
Yeah, it kinda blew my mind when I figured out that DOS was actually correct in that way, and unix was 'cheating' by magically inserting CR into the terminal codes.
I believe that it also has to do with the fact that at the time there no ‘screens’, only teletypers. So a new line is “return the carriage to the start” and “feed another line” (of paper) into the printer.
That doesn't quite fit the regular usage of the word. When someone asks you a question, you don't "return", but rather "respond" or "reply" or perhaps "submit" your response.
I think I have about a 50% success rate in typing a multiline message without accidentally sending it early, having to edit / copy and delete the message and finish typing it before the recipient has a chance to read it, confusing both me and them in the process.
A similar frustration / reason for getting it wrong sometimes: in slack, the behaviour of shift+enter entirely reverses if you're inside a multi-line code block. If you normally have enter to send and shift+enter to line break, then it'll do the opposite while inside a code block.
This is useful if you're trying to type verbatim inside a block, it's less so if you have a strong muscle-memory to shift+enter and do so while in the code block and find yourself sending half a message.
I also use a mixture of teams, discord and slack, and while slack does allow for customisations, I'd always rather get used to defaults to avoid having to configure on every machine I use.
There isn't quite a consistent well agreed default for the behaviour across applications, and that too is a source of frustration.
So I've taken to typing up any long messages in a PM to myself, and then copying that out to my intended target once I'm ready.
Indeed, it was browsing settings which made me realise the root cause of why I was accidentally sending so many messages.
But changing settings on platforms which I need to use across different computers and accounts is also cause for frustration, so I try to adapt to the defaults, no matter how frustrating.
> I think I have about a 50% success rate in typing a multiline message without accidentally sending it early, having to edit / copy and delete the message and finish typing it before the recipient has a chance to read it, confusing both me and them in the process.
That won't change if you had a different dedicated key for "move one line down but don't send `enter` keycode". You'd still accidentally hit `enter` due to muscle memory.
After all, if you could get past muscle memory, you'd simply press Shift while hitting Enter.
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 ?
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.
Sure, but sending a hypothetical combined CR+LF code (cf modern interpretation of CR) multiple times would accomplish the same thing, assuming there was no downside to performing CR when already at the start of the line.
Sure, I guess my point was that in the beginning, on old teletype systems, these were separate mechanical operations. Carrying them over as separate key codes made sense still because they had separate semantics to everyone at the time. Not that they didn't think combining them would be a good idea but that combining them didn't occur to the contemporaries at the time.
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.
Using NUL as the terminator would have been incredibly incompatible with Unix's choice of systems programming language. PC-DOS did not invent CRLF as the line terminator, it was already in common use in CP/M and VMS at the time.
Completely compatible, other than making most programs incapable of expressing multiple lines in one string that is. Or a partial line in a single string, since "end of line" and "end of string" would be indistinguishable.
This is conceptually confused. There are numerous ways to represent multiple lines in applications that want to operate on them, including separating them with LF, or any other code sequence ... but a better choice is using an array of pointers. As for partial lines, this is a matter of how one is semantically interpreting a string ... numerous C programs operate on lines with the LF stripped, and operate on all sorts of other strings, including substrings of lines.
Anyway, it's moot since UNIX didn't take this approach. I won't respond further.
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.
FTA: Apple also added Enter to the numeric keypad, although an Enter that almost exclusively did the same thing as Return.
If applications followed the UI guidelines, Enter behaved like Return if enter didn’t make sense in the context and vice versa. Yes, that was mostly (when do you have UI to enter a multi-line text to be processed as a separate unit?) but when it mattered, return started a new line, and enter sent entered text to be processed by the application.
MPW shell was a (?the?) prime example. In its editor, Return started a new line, Enter executed the current selection or, if there was none, line.
No, it works like that on mine. How amazing that I never noticed!
The habit of using Enter has been so ingrained for so many years that I never tried pressing Return before now. Has that always worked? I suspect that it didn’t at some point in the past, though it may be you have to go back a long way. Or perhaps I've been mistaken about this for decades and never realised…
On at least some Macs well into the 2000s, I remember that if you had a dialog with a text field in it, Return would add a new line in the text field, but Enter would _always_ choose the button with the thick black bar around it (typically "OK"). There were also some websites where OmniWeb (remember OmniWeb?) would interpret the Enter key (but not Return) as "click the 'next' link on this page", which was great for paging through webcomic archives and the like.
> [Apple] added Control next to Command, ensuring decades of confusion.
When Apple introduced the Macintosh II, buyers had the option to get a keyboard with the Macintosh layout, or the larger Apple Extended Keyboard with a mixed Macintosh/IBM PC layout.
The Apple Extended Keyboard was intended to be used with a IBM PC in a card slot.
That is why it has a layout like a IBM Model M with two Control keys.
It also has some sublegends that are PC-specific and otherwise didn't make sense on Macintosh.
But this keyboard got popular, and influenced its successors.
It's funny how HTML p tags and instant messaging apps have kind of brought back the distinction between "return" and "enter" where generally "shift-enter" means simple line-break/return, while regular "enter" means "new paragraph" or "send message".
Ive been finally learning a bit of Linux shell stuff and was disappointed when I realized that shells generally don't follow this paradigm unlike PowerShell consoles on Windows.
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.
Older (pre-1980 or so?) Swedish texts call it vagnretur. Literally a wagon (or carriage; Swedish has only a single word for those things) return. Guess English picked up the word carriage from French at some point and that word ended up being used for carriage return rather that wagon return that would have made as much sense to me, but that might sound weird to native speakers.
Why would wagon return make sense? I don’t see the connection. A carriage is something that holds things for transport. A wagon is specifically the wheeled thing that is pulled along. Typewriters aren’t wheeled transports.
I said "as much sense", not "more". I am just not used to a language that makes the distinction.
Doesn't seem perfectly consistent in English either. When there is a "wagon train" in a Western movie it is often full of people in wagons. Seems like wagon vs carriage is a bit more complex than just if it carries people or not?
There was a metal tooth that the shift lock engaged on the shift key below it, effectively "locking" the key carriage in place in the "shifted" position (caps lock for alphabetic characters, the "special" characters for the numerics).
To release it, you either pressed the shift key down, or pressed the shift lock again to "unlock" the shift.
No animals were harmed by the implementation of the tooth :)
His comment about how the ENTER key doing both newline and submitting data being confusing is very true. Gemini in AI Stuido and Claude handle this differently and it is so annoying.
> Finally, the team noticed one user that was particularly flummoxed by the dialog box, who even seemed to be getting a bit angry. The moderator interrupted the test and asked him what the problem was. He replied, "I'm not a dolt, why is the software calling me a dolt?"
ANSI vs ISO, there's qwerty ISO as well. There was a bigger enter key on older ANSI keyboards as well, they just shrank it at some point. Or so I thought. The backwards L key I had in mind is apparently a mix of the two. I just associate it with older keyboards.
Gotta love how inconsistent this is. The classic username/password dialog box, traditionally the first thing you see when starting your computer, would already have to treat the Return in a nonstandard way.
On my phone with 100% text size, I got a hyphen as follows:
“Manual hyphenation was not ad-
vised, either”
It is a very common older model iPhone, so I wonder if they lined that up on purpose. Brilliant, if so. It isn’t a manual hyphen, it just so happens to hit there.
I was considering a purchase, seeing as it is such a wealth of information and history. However, there are expletives in chapter titles! That’s a no-no for a collection-worthy book.
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.
The ↵ symbol was the Return symbol signifying the Return function. The textual legend "Enter" signified the Enter function, for data entry.
Some early Model F XT keyboards did not have stabilised keys so the touch-area had to be 1×1 with room only for ↵. From the Mode F AT (large backwards-L key) forwards however, the key did have both legends: ↵ and Enter. From there on, "Enter" is mostly just what IBM PC users called it.
There are other common misconceptions about key legends. For example that ↹ would mean Tab, when it is two symbols: ⇥ for Tab and ⇤ for Back-Tab. Back-tab is on the top because it is activated with Shift. (And again, some IBM terminal keyboards had separate Tab and Back-Tab keys. Apple keyboards have only the ⇥ symbol, BTW.)