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.

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.

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.

Nice solution for this might be:

Ctrl+Enter: Always submits

Shift+Enter: Always newline (if supported)

Enter: Reasonable default, depending on context

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

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.

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

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.

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.

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.

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.

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.

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.

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

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

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.

> 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

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

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

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?

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.

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

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

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

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

[dead]