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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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).
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.
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.
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.
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.
> 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] 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.
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.
48 comments
[ 2.6 ms ] story [ 58.2 ms ] threadIf 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.
The only thing I really use this for is renaming files in Finder: select a file and press Enter to edit the filename.
Are there any other apps in which it does something useful nowadays?
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.
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.
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.
(I guess the arrow's supposed to represents the movement of the cursor, not the paper/carriage.)
“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.
Why not “Sure”?
Also, the text is nicely readable but none of the images are viewable.
I wonder if hat word processors would have used a separate Enter (or Go!) for?
Even then I assume it was really a troll as much as anything else.
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.
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).
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 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.
in CR LF, the LF being there to account for timing as its tolerant of the return process still being in progress is genius.
https://en.m.wikipedia.org/wiki/Enter_key#/media/File%3AEnte...
https://commons.wikimedia.org/wiki/File:AT_keyboard_original...
https://commons.wikimedia.org/wiki/File:IBM_Model_M.png
https://www.daskeyboard.com/blog/wp-content/uploads/Cherry_k...
https://www.apple.com/shop/product/MXK83LL/A/magic-keyboard-...
I can't imagine any mainstream use where you'd want to enter a long sequence of symbols (!@#$% etc) needing Shift, other than letters.
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.
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.)
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.