Comment by uhoh-itsmaciek
14 hours ago
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.
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.
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.
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.
2 replies →
don't get me started on backspace vs delete...
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").
3 replies →
^H^H^H^H^?^?^?
1 reply →
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.
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.
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.
2 replies →
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.
Slack is similar Shift enter in normal text. Enter in a code block, shift enter sends in a code block.
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 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.
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.
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.
This is a user preferences setting for what it's worth.
Nice solution for this might be:
Ctrl+Enter: Always submits
Shift+Enter: Always newline (if supported)
Enter: Reasonable default, depending on context
> 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.
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.
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.
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.
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.
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.
> 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
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.
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.
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.
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.
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.
4 replies →
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.
This one has bitten me plenty of times, but the solution is what slack does: write underneath what you are supposed to do.
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.
The new idiom:
You are right, of course this is your account name! Do you want me to be keep you logged-in?
> _
A search box, I think
[dead]