sohkamyung•5d
The day Return became Enter (2023)aresluna.org
163 comments
  • Findecanor•22h

    > 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.)

    • chuckadams•18h

      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 remember when the ⌘ key was "open apple".

    • •18h
      [deleted]
    • kps•20h

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

      • dlcarrier•17h

        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.

      • Sharlin•19h

        "Next field" is sort of what tabulation means. Moving to the next column of a tabular form.

        • kps•18h

          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.

      • dfox•19h

        That is not an overloading, that is just preserving the behavior of Tab on IBM terminals.

      • Pxtl•17h

        Need an "indent" key distinct from the "tab" key.

  • rswail•1d

    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.

    • Animats•1d

      > 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.)

      • rswail•1d

        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 FS/GS/RS there.

        How were messages delimited in the polled multidrop environment?

        • Animats•15h

          > 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]

          [1] https://www.smecc.org/teleprinters/35selcall001.pdf

          [2] https://lostbits.net/blog/the-teletype-model-35-character-se...

          [3] https://youtu.be/PKJyGuhCQdQ?t=369

          [4] https://en.wikipedia.org/wiki/Plan_55-A

        • dfox•19h

          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.

        • varjag•23h

          TTY interfaces initially were teletypes on comms links.

      • ahazred8ta•17h

        Here's a pdf of a blank prop Western Union telegram form. Have you got others? https://www.hplhs.org/resources.php

    • arp242•21h

      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.

      • BeFlatXIII•17h

        Text editors should be programmed to support those separators. Would've saved us from CSV.

    • paffdragon•1d

      Wouldn't we still need a "Line Separator" character so we can include line breaks in fields and records for formatting purposes?

      • rswail•1d

        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".

    • fecal_henge•1d

      Also CSV files would not exist.

      • rswail•1d

        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.

        • bonzini•1d

          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.

        • UltraSane•21h

          I prefer alt 1 (smiley face) as a field separator. It definitely is rarely used in text.

    • Borg3•23h

      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?

      • saghm•21h

        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.

      • aleph_minus_one•19h

        > 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.

        • python-b5•17h

          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.

      • jibal•18h

        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.

      • chuckadams•18h

        > Who in his sane mind uses CRLF even under windows?

        Hopefully nobody is using it for documents, but most text-based internet protocols, including SMTP and HTTP, use CRLF for line endings.

      • mathiaspoint•20h

        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.

  • ochrist•1d

    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.

    • ahazred8ta•17h

      Some systems enforced CR LF NUL NUL NUL

  • weinzierl•1d

    We had distinct keys for Enter and Return for the longest time. An ISO standard keyboard has Return in the main block and Enter in the numpad.

    https://en.m.wikipedia.org/wiki/Enter_key#/media/File%3AEnte...

  • aag•1d

    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.

    • jama211•1d

      I wonder if I should make a joke menubar program where every time you make a newline while typing it sounds a slide-ding noise! I might do that…

      • i_am_proteus•1d

        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 :)

        • j4_james•20h

          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.

        • jama211•14h

          Hahaha, good point, you know I knew that but just didn’t think it through. I’d still like to make it though…

      • chuckadams•17h

        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...

        • jama211•14h

          Haha true, but they can be fun now too, nothing stopping us writing applications just for whimsy!

  • jasperry•1d

    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.

    • wpm•1d

      Every Apple keyboard, even the iPhone I’m typing this comment on, has had a Return key. Only the Num Pad has an Enter key on Apple’s keyboards.

      • unwind•1d

        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.

        • iamflimflam1•1d

          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…

          • wpm•15h

            Or Slack. Shift-Return for a new line, except if you're in a code block!

      • aldto•1d

        And Fn+Return can be used for Enter if the keyboard doesn't have a Num Pad, for the few Applications that use it.

        • jama211•1d

          Huh, TIL. I do wonder though what programs are looking so specifically for the exact Enter code.

      • jasperry•21h

        oh, thanks for the fact check. I guess it's obvious which computing ecosystem I never touch :)

    • kstrauser•1d

      The 2023 MacBook Air I'm typing this on has a return key.

    • robinsonb5•21h

      Yes indeed - and yet both the carriage and the paper move in the opposite direction compared with that arrow!

      (I guess the arrow's supposed to represents the movement of the cursor, not the paper/carriage.)

    • weinzierl•1d

      Same for me. It had the smell of professionalism. Even more than for an Enter key I longed for the luxury of four distinct cursor keys.

    • hulitu•1d

      > I guess there's no other symbol that would convey the meaning of Enter as well.

      Just wait until UI mafia from Microsoft, Apple or Google find about this. They will come with a new symbol every 3 months.

  • OhMeadhbh•19h

    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.

  • kimixa•1d

    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.

    • Doxin•1d

      Perhaps a confused translation of escape/enter happening there? I don't think there's many (if any) PCs with both a return key and an enter key.

      • brianpan•1d

        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".

        https://en.wikipedia.org/wiki/Model_M_keyboard

        EDIT: Holy cow, those Model M pictures are so nostalgic.

      • kimixa•1d

        No, I definitely remember it behaving differently if I pressed "return" (right of "#" on the keyboard) vs "enter" (on the numpad).

        EDIT: In the US I guess that's right of "'"? Below backspace, above the right shift.

        The reason I remember is it took me quite a while to actually run the damn thing :P

  • layer8•1d

    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.

  • ogab•16h

    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?

  • jccalhoun•23h

    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.

  • usr1106•1d

    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.

    • yencabulator•18h

      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.

    • SoftTalker•1d

      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").

      • chowells•1d

        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.

        • rswail•1d

          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.

  • HarHarVeryFunny•18h

    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 ?

    • kevindamm•18h

      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.

      • HarHarVeryFunny•17h

        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.

  • fedeb95•23h

    We need two keys, one for new line inside a MS Teams message, the other for sending the message

    • pytness•23h

      We already have two keys, they are called Shift and Enter

      • sippeangelo•23h

        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.

        • xnorswap•22h

          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.

          • arp242•21h

            > in slack, the behaviour of shift+enter entirely reverses if you're inside a multi-line code block

            There's a setting to turn that off so it behaves consistently. Or there was last time I used Slack.

            • xnorswap•21h

              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.

            • pletnes•21h

              Thanks!

        • lelanthran•22h

          > 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.

        • pytness•23h

          Same but with editing a message on a browser and trying to delete a word with Ctrl+w

      • fedeb95•23h

        yes but you have to type sfhit+enter, while a single "new line key inside the message" would be better for the specific task.

  • Bjartr•18h

    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"

    • qwertygnu•16h

      A lot of people talk like this too. I'm sure I'm a little too literal, but IMO most people are too clickbait-y.

  • userbinator•1d

    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.

    • vmladenov•1d

      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.

      • opan•1d

        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).

    • gyomu•1d

      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.

      • rswail•1d

        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.

        • bregma•23h

          > 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.

      • esafak•1d

        Going to a new line is "line feed", hence the combo CR/LF.

        • flomo•1d

          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.

        • ArnoVW•1d

          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.

    • wpm•1d

      You’re “returning” whatever text you typed to the program accepting input.

      • falcor84•1d

        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.

        • userbinator•1d

          Some people will "revert", which doesn't help matters much either.

  • jfultz•18h

    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.

  • jibal•18h

    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.

    • chuckadams•17h

      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.

      • jibal•17h

        No, it would have been completely compatible with C ... that's the point.

        • chuckadams•17h

          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.

          • jibal•16h

            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.

  • cwmma•18h

    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...

  • Findecanor•22h

    > [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.

  • Someone•5d

    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.

    • etbebl•1d

      I have a faint memory of Enter creating a page break rather than a newline on a school Mac when I was a kid. Maybe that was in AppleWorks?

      • ochrist•1d

        I modern Word you can use Ctrl + Enter to create a page break.

      • dkga•1d

        I wouldn’t doubt it, the way some Mac keys are completely unintuitive.

    • robinhouston•1d

      On a current Mac laptop, you can still press fn + return to get the effect of the Enter key.

      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?

      • littlecosmic•1d

        On my 16" M1 MacBook Pro both Return and Fn+Return edit the filename... does it work differently on yours?

        • robinhouston•23h

          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…

    • YZF•1d

      My 2013 MBP says `enter` above `return` ... Presumably shift is the modifier (I never use it).

    • blahedo•1d

      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.

  • 3036e4•1d

    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.

    • adastra22•1d

      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.

      • Etheryte•1d

        It makes sense because it's the same word in Swedish, the distinction doesn't exist.

      • amszmidt•1d

        A carriage is a wagon that transports people, not "things", a carriage are also usually wheeled, just like wagons.

        In this case, one reason why "wagon return" might have made more sense is because there is a wagon that holds the platen of the typewriter.

      • GLdRH•1d

        Carriage is another word for wagon (german Wagen, swedish vagn)

    • reddalo•1d

      In Italian it's called "carrello", which mean cart. Cart makes more sense than carriage, IMO.

  • strken•1d

    When the essay says "a literal tooth", does it really mean a literal calcium tooth from some animal's mouth?

    • rswail•1d

      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 :)

    • anotherhue•1d

      No those would be "literal canines", i.e. grammatical assistance dogs.

      • syncsynchalt•11h

        In some industries, latches (which the article called "teeth") are called "dogs".

        So that's a full-circle kind of comment you've got there.

  • mproud•1d

    Keys are often replaceable; and we can put our own labels on them.

    Why not “Sure”?

    • IgorPartola•1d

      Make it so.

      Proceed.

      Engage.

      Take that!

      En Garde!

      Go!

      Blam!

      Start your engines!

      Yes.

      Forward.

      Eh, good enough.

  • k__•1d

    How come the enter key is so small on most qwerty keyboards I've used and so big on the qwertz ones?

    • opan•1d

      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.

      https://superuser.com/a/1368499

      Personally I use a Pinky4 keyboard where every key is 1U these days, even space and enter.

  • indyjo•1d

    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.

  • bee_rider•1d

    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.

    • tomr_stargazer•1d

      I got lucky in a different spot:

      "Manual hy-

      phenation was not advised, either."

    • eternauta3k•1d

      If you want more of these jokes in the structure and flow of the text you should read Gödel Escher Bach.

  • maxlin•1d

    Good read, I didn't realize how much diversity there was in those buttons. Thought it was just a few different options!

    in CR LF, the LF being there to account for timing as its tolerant of the return process still being in progress is genius.

  • Pxtl•17h

    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.

  • UltraSane•21h

    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.

  • lloydatkinson•1d

    TIL that Shift Lock used to exist. What a shame it doesn’t anymore.

    • HarHarVeryFunny•20h

      Given that you've got Caps Lock, what would be the use for Shift Lock?

      I can't imagine any mainstream use where you'd want to enter a long sequence of symbols (!@#$% etc) needing Shift, other than letters.

  • transfire•1d

    I agree. Separate keys would be better.

    I wonder if hat word processors would have used a separate Enter (or Go!) for?

  • code_martial•1d

    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.