Decades ago, Return and Enter were two different keys for that reason: Return to insert a line break, Enter to submit your input.

Given the reduction to a single key, the traditional GUI rule is that Enter in a multiline/multi-paragraph input doesn’t submit like it does in other contexts, but inserts a line break (or paragraph break), while Ctrl+Enter submits.

Chat apps, where single-paragraph content is the typical case, tend to reverse this. Good apps make this configurable.

Before that, page-mode terminals used <Return> to move to first field on a subsequent line (like a line-based <Tab>) and sent the page only on <Enter> or <Fn-key>. This made for quick navigation w/ zero ambiguity.

don't get me started on backspace vs delete...

^H^H^H^H^?^?^?

That evil laughter from a disobedient tty. :(

not just that ... plenty of web apps (and maybe desktop native ones too, though I don't notice it as much there) use "smart-delete" - if the cursor has a character after it, the delete key deletes it, but if not, it operates like backspace (which ought to be labelled "delete prev").

I haven’t happened to have seen that - which web apps do it?

Hmm, at this point I think I might be imagining it ... I'll let you know if I can find it ...

Some older Apple keyboards had their backspace button labelled “delete” which to me made it sound like that was the “del” button and not the backspace button.

That was the convention on many older computing platforms.

A "Backspace" key on a typewriter did not actually delete: It merely moved the typing position back one space.

Carriage return and line feed go way back. Tty stands for teletype. A computer was the job description of a person.

It’s turtles all the way down.

What lower turtles were there? My impression was that teletypes were the first proper keyboard-based interfaces.

The telegraph was keybased - only one key so I can't call it a keyboard, but in other ways it is what you are asking about.

Pianos have keys. And some telegraphs were outfitted with piano-like keyboards with one key per letter. Wikipedia has some pictures in the printing telegraph article [1]. So there is arguably a clear lineage from pianos to the modern computer keyboard.

Pianos however don't really have a concept of advancing the line or sending a recorded message.

1: https://en.wikipedia.org/wiki/Printing_telegraph

player pianos existed with the concept of advancing are recorded messages. I forgot about them until you metioned them. The music box goes way back

Now I am searching to see if there were models of player pianos intended to punch tape.

I have never really thought about it but a player piano sort of implies it can only play the roll. If pressed I would guess that player piano rolls were cut by hand. I mean, I am sure they had tools to help them and probably fully automatic duplication machines. but did anyone play the piano to get a piano roll? or was it more like transcribing sheet music?

here were pianos that could punch a roll, but they were rare - AFAIK there were one offs that the company who made rolls used. The better rolls labels "as played by [someone famous in 1920]" were played on such a system. Once in a while those rolls were used directly in a performance, but the most common use was an expert would use that as the master and then correct all the errors because the transcription system wasn't very accurate (I'm not sure in what way, only that the companies always had an editor make adjustments before selling those roll)

Some of them are on exhibit in a museum - but with a sign saying something like "this will never be restored because it exposes the user to poisonous mercury." If you want to know more join the Musical Box society (I'm a member), or one of the other international clubs for people who collect this type of thing (I know of several but since I'm not a member I can't remember the full name)

Mechanical typewriters have different physical mechanisms to feed forward a line or make the carriage return. I think it doesn't turtle much further back than that.

Well around the time of the first typewriters (late 19th century) there where mechanical typesetters, automating the laborious task of typesetting for the printing press. Of course the mechanics of printing where different but as far as I know this is the source of the "keyboard with buttons" type interface for producing literature.

> My impression was that teletypes were the first proper keyboard-based interfaces.

They (about) were, AFAIK, but using them with computers wasn’t their first usage.

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

“A teleprinter (teletypewriter, teletype or TTY) is an electromechanical device used to send and receive typed messages through various communications channels

[…]

Initially, from 1887 at the earliest, teleprinters were used in telegraphy. Electrical telegraphy had been developed decades earlier in the late 1830s and 1840s, then using simpler Morse key equipment and telegraph operators

[…]

With the development of early computers in the 1950s, teleprinters were adapted to allow typed data to be sent to a computer”

Even for that, there was prior art. https://en.wikipedia.org/wiki/Printing_telegraph, which used a piano-style keyboard.

The Linotype also is quite old. https://en.wikipedia.org/wiki/Linotype_machine:

“The Linotype machine operator types text on a 90-character keyboard.

[…]

In July, 1886, the first commercially used Linotype was installed in the printing office of the New York Tribune.”

Microsoft teams: not as bad as people say, except for this situation.

I have accidentally sent so many messages trying to get to a new line.

I also sent a LOT of Slack messages prematurely for the same reason. Used to it now, though. The more an interface emphasises the single-line nature of a text input, the better. Multi-line should never submit on enter, single-line always should.

Same, but it's configurable in slack so now I have it configured the Enter inserts a line break and Cmd+Enter submits the message

while I haven't changed it, it seems that you configure that behavior in the current version of Teams (Settings > Chats and channels)

It's because enter does different things at different times in the exact same text box.

Write a code snippet/block text. Does [enter] insert a newline, exit the block, or send the message?

What about in a bulleted or numbered list?

And my 2 biggest pet peeves with MS Teams:

1. trying to edit the first letter in a `preformat block`. It's not possible. It will either exit the block or go to the second letter.

2. Consistency with bold/italics. Bold a selection of text. Then backspace once. Are you going to write bold or normal? What does ctrl-B do? Anytime you backspace into a bolded section, it will convert your editing back to bold, and you cannot disable bold.

I have a very small Kevin Bacon number to the "guy who runs Teams". The message from them is "please use the built-in feedback tool to tell us about these things".

Teams does both - normally it’s Enter to submit and Shift+Enter for a new line, but when you open the formatting tools it switches. They at least do have a message indicating which key combo inputs a new line, but it still gets me on occasion.

Slack is similar Shift enter in normal text. Enter in a code block, shift enter sends in a code block.

I just tested this on Slack (macOS) and it's not the case. Pressing Enter in a code block submits the message, just as it does for any message.

The Signal desktop app does both too, I guess, but in a way that actually makes sense. Enter sends a message since IMs tend to be short one-liners. Shift-Enter inserts a line break.

But if you click an arrow on the top of the text box, it expands to more than half of the height of the window, and now Enter does a line break and Shift-Enter sends. Which makes a lot of sense because now you're in "message composer" / "word processor" mode.

I would say it mirrors common behavior in the Web, which in turn was largely influenced by old desktop software: Enter in a `<textarea>` inserts a line break, while enter in an `<input>` submits the surrounding form (or does nothing). It is an established idiom after all, many apps just get it wrong.

I have a very mild jolt of anxiety every time I want to enter a new line in Teams or Slack, wondering if it will send a half completed message I will need to edit after the recipient has seen the half completed message, or it will enter a new line like I want it to.

The behavior also changes if you start editing a numbered or unordered list. Maybe that enters the "formatting tools" mode you mention?

If you're worried about this, consider a copy and paste from notepad.

Note the "very mild" jolt, not quite enough to rise to the level of switching to Notepad (or Emacs in my case).

Your advice beautifully reinforces OP's case. We now have to use auxiliary apps with more predictable behaviour because designers made such a mess of things.

We've still yet to reach the "any textbox is just an embedded version of your EDITOR" nirvana.

Shift enter should always put in a new line. Good luck exiting a block though with it.

Teams is insane. You want a new entry in a bulleted list? Hit the enter key. If you dare.

I had managed to be on Slack exclusively for at least 10 years. Recent acquisition has me using Teams and it's hilarious to see for the first time what people have been complaining about. I thought surely people are exaggerating. No, no they are not.

It only took a couple weeks for me to figure out that I would have to compose longer messages somewhere else and then paste them into Teams.

Teams also respects some standard markdown, like italics, but not others…like bold.

MS is amazing in their ability to fuck shit up for no apparent reason. Like making a media player that doesn’t use space for play pause…

Unfortunately, some markdown renders differently when copied in vs when typed directly in teams.

In Slack it can get even worse.

If you turn on Markdown formatting, shift+enter adds a new line, unless you’re in a multi-line code block started with three backticks, and then enter adds a new line and shift+enter sends the message.

I can see why someone thought this was a good idea, but it’s just not.

This is a user preferences setting for what it's worth.

It’s kind of modal editing. Your 99% is enter to send because it’s a chat program. You’re sending mostly quick messages where adding a chorded input to send is just adding extra work to that mode.

When you enter a code block, that assumption changes. You are now in a “long text” mode where the assumptions are shifted where you are more likely want to insert a new line than to send the message.

I think people that have used tables or a spreadsheet and a text editor kind of understand modal editing and why we shift behaviors depending on the context. Pressing tab in a table or spreadsheet will navigate cells instead of inserting a tab character. Pressing arrow keys may navigate cells instead of characters in the cell. Pressing enter will navigate to the cell below, not the first column of the next row. It’s optimized for its primary use case.

I think if the mode change was more explicit it’d maybe be a better experience. Right now it is largely guessing what behavior someone wants based off the context of their message but if that mismatches the users expectations it’s always going to feel clumsy. A toggle or indicator with a keyboard shortcut. Can stick the advanced options inside the settings somewhere if a power user wants to tinker.

> I think people that have used tables or a spreadsheet and a text editor kind of understand modal editing and why we shift behaviors depending on the context.

I don't have a spreadsheet software nearby, but I remember the cell is highlighted different if you're in insert mode or navigation mode. Just like the status line in Vim let's you know which mode you're in.

The worst part is if I paste markdown it's not formatted automatically.

Ctrl-shift-f to apply formatting to literal markdown that's been entered via pasting

When you're in a multi code block it should simply never send on (shift+)enter then. Close the code block first.

There's a setting to toggle this behavior

Thats funny because I thought it was shift-enter that creates a newline in a field where an enter submits. Just shows the fractured nature of this whole thing.

This is my thinking. Ctrl-Enter is usually "submit the form this input is a part of" in my experience, especially if you're in a multilinear text input (or textarea).

I've seen Enter, Shift-Enter, Ctrl-Enter, and Alt-Enter, (and on macOS, Cmd-Enter and Option-Enter), depending on the application. Total circus. I think this is actually a weakness of the standard keyboard: Keyboards should at the very least separate "submit form / enter" from "newline / carriage return" with different physical keys, but good luck changing that one, given the strong legacy of combining these functions.

I've found Shift+Enter to do this pretty reliably across systems whatever they've chosen Enter / Ctrl+Enter to do.

It even works inside bullet points to add separate lines as part of the same bullet.

For Slack at least you have the option to change that back to use Enter for new line (which is what I do), but other software is not that generous. I think Grafana introduced yet another way, Shift-Enter to submit, that I alway mix up.

Hot take — Shift enter to submit should be illegal everywhere. If there's any key chord to submit, it should be Ctrl Enter.

I think I'd be OK with some inconsistency in how Enter works as long as the key chords are consistent!

macOS is slightly more consistent among apps that use system controls, but the more custom the app, or the more React Native or Electron it is, the less predictable it is

Infuriatingly, some apps try to be smart — only one line, return submits; more than one line, return is a new line, and command-return submits; but command-return on just one line beeps an error.

Years of muscle memory are useless, so now I’m reaching for the mouse when I need to be clear about my intent

So much is solved when developers just use the provided UI controls, so much well-studied and carefully implemented behavior comes for free

Using provided UI controls is consistent with how today's apps behave on mobile:

- For single-line text fields, pressing enter is an alias for submitting the form. - For multi-line text fields, pressing enter inserts a new line. There is no shortcut for submitting the form.

In mobile chat apps, the enter key inserts a new line, so you have to press the non-keyboard submit button to send a message. In mobile browser address bars, since they are single-line text fields, the enter key becomes a submit button on the virtual keyboard.

> - For single-line text fields, pressing enter is an alias for submitting the form. - For multi-line text fields, pressing enter inserts a new line.

Web browsers have been like that by default for ages in text input (single line) vs textarea (multi line). Since way before smartphones even existed.

Regardless, many chat apps on the computer have what look like a multi line textarea but it will be anyone’s guess whether Enter will add a newline or submit in any particular one of them.

> Infuriatingly, some apps try to be smart — only one line, return submits

Tbf, this is almost certainly what the vast majority of people want, most of the time, from chat apps like Slack. It would be much more frustrating to have to click a button after each thought.

Apart from a chat interface, when should enter ever submit your text?

A single-line text box that has no possibility of multi-line text (so, not a chat interface), such as search, an address bar, something that's obviously "submit one item" (e.g. "submit a word"), etc.

In a multiline text box, enter should NOT submit the form. Chat interfaces violate this rule and it results in lots of premature chat submissions.

Precisely. 'member CUA?

In single-text-input contexts, like search fields and the browser address field, and things like Save As dialogs. It’s the general expectation for dialogs with an OK or default button, just like Escape cancels the dialog.

A search box, I think

The new idiom:

You are right, of course this is your account name! Do you want me to be keep you logged-in?

> _

Anything which supports multi-line input shouldn't submit on enter it should submit on button press so anyone can use it instantly without learning or remembering anything.

Then make it easier for users to learn that they can enter more quickly with control+enter which you can advertise via tooltip or adjacent text.

Better that 100% find it trivially usable even if only 75% learn they can do it faster

That isn’t workable for chat apps, at the very least on mobile. And that’s the most-used text entry interface that users nowadays grow up with. So I think you need to make an exception for such applications.

Mobile makes this much easier actually, send can be a different button on the UI than the newline button on the touch keyboard without having to teach this to users. That's exactly how my phone is currently configured at least.

I don’t understand what difference you are seeing. On the desktop you would have a UI button as well, and likewise a key on the keyboard.

The difference I’m referring to is that Ctrl+Enter is arguably acceptable on the desktop, but has no equivalent on touch keyboards on mobile.

Regarding the UI button, the way many people chat they would consider it too much friction to have to tap a button above the keyboard for every send — more friction than Ctrl+Enter is on the desktop,

No one uses the UI button to send a message on the desktop though. Everyone just presses Return to send, which is the most common need, and then once in a while realise they need to enter a newline without sending, for which there isn't a button so they need to learn how.

Mobile doesn't necessarily have this issue because it can show the send button and the newline button at the same time and they're equally accessible.

Regarding your edit:

> they would consider it too much friction to have to tap a button above the keyboard for every send

My finger travels almost the same distance from the home row to hit the send button above the upper right corner of the keyboard as the newline button on the lower right. I've been doing this for ages.

Actually, I do. Or at least I do in very similar situations where for some reason there is no keyboard shortcut to submit from the input field, so I press Tab (which moves the keyboard focus to the submit button next to the text field) and then press Return or Space to press the UI button.

Regarding on mobile, I’m familiar with chat apps that require a UI button press to send, and consider it unnecessary friction. It’s a larger mental leap to have to leave the keyboard.

> It’s a larger mental leap to have to leave the keyboard.

I find this interesting! I've never considered myself "leaving the keyboard" on the phone as if I were task switching. When I'm done typing I flow directly to the send button and let the keyboard go. The fact that the button is above the keyboard makes no difference to me as long as it stays accessible.

Mobile keyboards also do have the advantage that they can at least change the label of the button; so writing Submit on the Enter key if it submits.

> so I press Tab

Now you have a bonus problem: how do you insert a Tab in a multi-line text box?

This one has bitten me plenty of times, but the solution is what slack does: write underneath what you are supposed to do.

PSA: CJK input frameworks(IMEs) use both Space and Enter for doing Hanzi/Kanji. Naively rigging Enter in JS to send causes wrong homonyms and/or raw phonetic scripts to get sent. There are few ways to resolve this issue, of which the easiest is to just leave Enter to the operating system.

Sometimes it's shift enter too! I am having a hard time keeping this straight between applications.

Today I’m thoroughly confident that if I sit in front of an AI chatbot/TUI/whatever. I will invariably fail at knowing which key combo sends the input and which enters a new line. It’s maddening.

I don’t understand why we ever let plain Enter send a prompt out.

Yeah this is insane. Maybe most users of chat bots are just sending one line prompts but I find that hard to believe users of Claude code are doing that more often than sending multi-line prompts.

Slack requires shift+enter to create a new-line, while in JIRA shift+enter creates a new-line instead of new paragraph, creates all sorts of confusing layout issues, and because the difference is invisible, it's hard to to figure out where/when you've made this mistake of using shift+enter instead of just enter.

Nearly drove me insane, until I developed separate muscle memory between the two apps/sites.

Nice solution for this might be:

Ctrl+Enter: Always submits

Shift+Enter: Always newline (if supported)

Enter: Reasonable default, depending on context

I thought this is how it works for most software. What are the exceptions to this rule?

This is a lot of pain.

It is very easy to fix. Add button somewhere around text box. Which turns it into multiline text edit control, increases its height. Now <Enter> works as line feed and to submit the text user have to click "send" button. Most of chat messages are not multi-line, but few are and for them, proper edit UI is essential.

I, personally, just use separate text editor like Gnome Text Edit to compose my message and then Ctrl+C/Ctrl+V to send it.

I think this is just doing things differently, not fixing them - and IMO not for the better either.

I've been playing with making a chatbot with llama.cpp and FLTK[0] and FLTK's default behavior is actually to add a newline in the multiline editor when pressing Enter even if a 'Return button' is in the form (Return buttons are buttons activated when you press Enter or Return though Return is also handled kinda differently). And i have a big Submit 'Return button' there.

And TBH it annoyed me a LOT that i have to move the mouse and press the button to submit or that Enter adds newlines instead of submitting so that i explicitly added code so that pressing Enter is not handled by the editor (letting the Return button submit the input) and pressing Shift+Enter is what adds the newline (Ctrl+Enter also works, this comes from FLTK's behavior, but i've been used to Shift+Enter myself).

Which is basically how pretty much every chat interface (be it AI chatbot or something like Discord or whatever) that i've used in recent times works. And TBH it makes sense to me that the simplest/easiest shortcut (Enter) is what does the most common thing (send text) in a chat interface whereas the more involved shortcut (Shift+Enter or Ctrl+Enter) is used for the exceptional/less common case. In such an interface, the multiline editing is there as an exception (for when you want to paste some stuff and even then often Ctrl+V by itself can be enough), but most interactions are going to be single line submissions (often wordwrapped to look like multiple lines but still a single line).

[0] https://i.imgur.com/K3m9KAD.png

> you're probably more likely to want fancier formatting in a PR review comment than a chat message.

Exactly, and that's how you keep track

for this reason I use shift+enter. I'm blind and not sure if it starts a new paragraph or is just a paragraph break, but works well enough in my experience.

> and ctrl-enter forces a newline (not at my computer, but I think Slack does this)

Slack also has the option to invert this in settings. I always have it inverted, so that I can freely type multiline messages, and require the more intentional ctrl-enter to actually send.

> I don't know how we got here

I have a suspicion — it has to do with instant messaging clients. The idea being that you want to type short one-line messages and send them as quickly as possible in most cases, but in a rarer case when you do want a line break, that's Ctrl+Enter or Shift+Enter. Probably the first one where I personally encountered "enter is send" is ICQ, but I'm sure it's older than that, I would be surprised if no IRC clients did that.

Win32 standard multiline edit controls use Ctrl+Enter to insert a newline (instead of pushing the default button or "submit" action on a dialog), so that may be where the idiom came from.

For me, Enter to send and Ctrl+Enter for newline is the norm in an IM application, while longer and more asynchronous communication (like this textbox on HN for commenting, or a forum post, or an email client) implies that Enter inserts a newline and something more substantial (Alt+S is common, or Tab,Enter to move to and press the submit button) submits.

I think this one is easy to explain: it's a clash between chat idioms and forum idioms. Chats since IRC have had Enter=Send because messages were supposed to be single line, while web forums have had multiline text editors from the start so Ctrl+Enter=Send made the most sense. As the two merged, confusion and conflict was inevitable.

We can easily fix this by just letting everyone choose, but no one wants to make configurable UX.

> while web forums have had multiline text editors from the start so Ctrl+Enter=Send made the most sense

This is normal/standard behavior for multiline inputs such as the textarea, while input type=text/search/email will trigger a submit.

https://html.spec.whatwg.org/multipage/form-control-infrastr...

So basically a chat input based on web technology is saying:

"I'm a single line input, but will allow multiline editing if you ask nicely"

>"bring back idiomatic design" doesn't help when we don't have enough idioms

One must always research and find the dominant or most applicable idioms for whatever they're doing. Are you building a command line tool? For which platform? What other similar tools are you basing its design on? You have to check yourself and see whether your software conforms to the idioms of the platforms, communities, etc that you're targeting.

Enter-to-send is horrible.

ChatGPT does it.

Claude does it.

Nextdoor does it.

And none of those give you the courtesy of being able to turn it off.

Slack does it, but if you dig through the settings you may find the way to switch it.

How on earth did so many "designers" fixate on this idea that we must want to share our thought immediately instead of allowing a calmer interaction?

I can kinda understand why ChatGPT and other chat bots do it. It's a chat interface. Most people chat with single line prompts.

Next door and social media apps, to answer your question, I'm sure a PM somewhere was able to prove that engagement increased if we let people share their thoughts immediately, and the PM got a tidy bonus because of this.

I would be OK if they put a checkbox next to the text input that let me choose whether enter sends or line breaks. I would be OK even if that lived in session storage, to remove the friction of a new Db column. Just give us the option!

It's even worse on some websites. For example, Grok sends on enter. Even on mobile. Where you can't even press ctrl+enter, because mobile software keyboards don't have a control key. So you can't include line breaks at all when talking to Grok. You can merely accidentally send a message prematurely. (Maybe they have fixed it by now.)

Sometimes it's ctrl-enter. Sometimes it's shift-enter. ARGH!

> In text boxes in some applications, enter submits the entered text...

On Mac it's also not unusual that the Enter key is linked to the outer window's Ok button even when an a text input field is active (for instance in the "new" settings panel when trying to enter a DNS server address - pressing Enter closes the entire DNS panel, infuriating if you want to add more than one DNS server).