7 ms·

In text boxes in some applications, enter submits the entered text, and ctrl-enter forces a newline (not at my computer, but I think Slack does this). In other

In text boxes in some applications, enter submits the entered text, and ctrl-enter forces a newline (not at my computer, but I think Slack does this). In others, it's the other way around (pretty sure GitHub does this for comments). I don't know how we got here and I don't know how to fix it, but "bring back idiomatic design" doesn't help when we don't have enough idioms. I'm not even sure if those two behaviors are wrong to be inconsistent: you're probably more likely to want fancier formatting in a PR review comment than a chat message. But as a user, it's frustrating to have to keep track of which is which.

Nemi 6mo ago
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.
- lytedev 6mo ago
  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).
- ryandrake 6mo ago
  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.
- Izkata 6mo ago
  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.
rightofcourse 6mo ago
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.
- abustamam 6mo ago
  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!
carlosjobim 6mo ago
Apart from a chat interface, when should enter ever submit your text?
- somehnguy 6mo ago
  A search box, I think
- binarymax 6mo ago
  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.
  - owlstuffing 6mo ago
    Precisely. 'member CUA?
- layer8 6mo ago
  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.
- JoshTriplett 6mo ago
  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.
- masswerk 6mo ago
  The new idiom: You are right, of course this is your account name! Do you want me to be keep you logged-in? > _
physicles 6mo ago
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.
- jwolfe 6mo ago
  This is a user preferences setting for what it's worth.
- least 6mo ago
  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.
  - skydhash 6mo ago
    > 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.
AgentEpsilon 6mo ago
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.
- darrylb42 6mo ago
  Slack is similar Shift enter in normal text. Enter in a code block, shift enter sends in a code block.
  - oneeyedpigeon 6mo ago
    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.
- andrepd 6mo ago
  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.
  - phil294 6mo ago
    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.
- jimbokun 6mo ago
  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?
layer8 6mo ago
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.
- jeberle 6mo ago
  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.
- irishcoffee 6mo ago
  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.
  - falcor84 6mo ago
    What lower turtles were there? My impression was that teletypes were the first proper keyboard-based interfaces.
    - bluGill 6mo ago
      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.
      - wongarsu 6mo ago
        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 https://en.wikipedia.org/wiki/Printing_telegraph
michaelmrose 6mo ago
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
- layer8 6mo ago
  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.
  - debugnik 6mo ago
    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.
    - layer8 6mo ago
      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,
      - debugnik 6mo ago
        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.
jmbwell 6mo ago
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
- sheept 6mo ago
  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.
  - deleted 6mo ago
    [deleted]
  - QuantumNomad_ 6mo ago
    > - 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.
- oneeyedpigeon 6mo ago
  > 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.
ErigmolCt 6mo ago
[dead]
tomjen3 6mo ago
This one has bitten me plenty of times, but the solution is what slack does: write underneath what you are supposed to do.
numpad0 6mo ago
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.
the__alchemist 6mo ago
Sometimes it's shift enter too! I am having a hard time keeping this straight between applications.
yoz-y 6mo ago
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.
- abustamam 6mo ago
  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.
cstrahan 6mo ago
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.
trelbutate 6mo ago
Nice solution for this might be: Ctrl+Enter: Always submits Shift+Enter: Always newline (if supported) Enter: Reasonable default, depending on context
- timokoesters 6mo ago
  I thought this is how it works for most software. What are the exceptions to this rule?
vbezhenar 6mo ago
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.
- badsectoracula 6mo ago
  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 https://i.imgur.com/K3m9KAD.png
eviks 6mo ago
> 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
gostsamo 6mo ago
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.
swiftcoder 6mo ago
> 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.
grishka 6mo ago
> 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.
userbinator 6mo ago
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.
cyberrock 6mo ago
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.
- dgb23 6mo ago
  > 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-infrastructure.html#implicit-submission 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"
marxisttemp 6mo ago
>"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.
Stratoscope 6mo ago
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?
- abustamam 6mo ago
  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!
cubefox 6mo ago
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.)
QuercusMax 6mo ago
Sometimes it's ctrl-enter. Sometimes it's shift-enter. ARGH!
flohofwoe 6mo ago
> 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).

Nemi 6mo ago

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.

lytedev 6mo ago
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).
ryandrake 6mo ago
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.
Izkata 6mo ago
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.

rightofcourse 6mo ago

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.

abustamam 6mo ago
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!

carlosjobim 6mo ago

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

somehnguy 6mo ago
A search box, I think
binarymax 6mo ago
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.
- owlstuffing 6mo ago
  Precisely. 'member CUA?
layer8 6mo ago
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.
JoshTriplett 6mo ago
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.
masswerk 6mo ago
The new idiom: You are right, of course this is your account name! Do you want me to be keep you logged-in? > _

physicles 6mo ago

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.

jwolfe 6mo ago
This is a user preferences setting for what it's worth.
least 6mo ago
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.
- skydhash 6mo ago
  > 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.

AgentEpsilon 6mo ago

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.

darrylb42 6mo ago
Slack is similar Shift enter in normal text. Enter in a code block, shift enter sends in a code block.
- oneeyedpigeon 6mo ago
  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.
andrepd 6mo ago
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.
- phil294 6mo ago
  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.
jimbokun 6mo ago
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?

layer8 6mo ago

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.

jeberle 6mo ago
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.
irishcoffee 6mo ago
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.
- falcor84 6mo ago
  What lower turtles were there? My impression was that teletypes were the first proper keyboard-based interfaces.
  - bluGill 6mo ago
    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.
    - wongarsu 6mo ago
      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 https://en.wikipedia.org/wiki/Printing_telegraph

michaelmrose 6mo ago

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

layer8 6mo ago
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.
- debugnik 6mo ago
  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.
  - layer8 6mo ago
    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,
    - debugnik 6mo ago
      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.

jmbwell 6mo ago

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

sheept 6mo ago
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.
- deleted 6mo ago
  [deleted]
- QuantumNomad_ 6mo ago
  > - 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.
oneeyedpigeon 6mo ago
> 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.

ErigmolCt 6mo ago

[dead]

tomjen3 6mo ago

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

numpad0 6mo ago

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.

the__alchemist 6mo ago

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

yoz-y 6mo ago

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.

abustamam 6mo ago
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.

cstrahan 6mo ago

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.

trelbutate 6mo ago

Nice solution for this might be: Ctrl+Enter: Always submits Shift+Enter: Always newline (if supported) Enter: Reasonable default, depending on context

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

vbezhenar 6mo ago

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.

badsectoracula 6mo ago
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 https://i.imgur.com/K3m9KAD.png

eviks 6mo ago

> 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

gostsamo 6mo ago

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.

swiftcoder 6mo ago

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

grishka 6mo ago

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

userbinator 6mo ago

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.

cyberrock 6mo ago

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.

dgb23 6mo ago
> 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-infrastructure.html#implicit-submission 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"

marxisttemp 6mo ago

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

Stratoscope 6mo ago

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?

abustamam 6mo ago
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!

cubefox 6mo ago

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

QuercusMax 6mo ago

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

flohofwoe 6mo ago

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