Avoiding Slack Accidentally Sending Messages Mid Code-Block

I know that I'm far from alone in not particularly liking Slack, nor am I likely to be the first to observe that it seems to be particularly bloated case-study in poor UI/UX design.

But, whether I like it or not, Slack is something that I have to use quite regularly, annoyances and all.

One of the more annoying defaults is the way that the handling of Enter/Return can change mid message:

For a newline in a message, you press <shift+enter>
Now you're on a newline.

```
Now though, you're in a codeblock
for a newline you need to press <enter>
if you hit <shift+enter> it'll send the part written message
```

Now that you're back out of the code block,<enter> will send
<shift+enter> will add a newline

Inevitably, this leads to message threads getting disrupted by part-finished messages, followed by a simple message before the hurried editing starts:

Screenshot of a slack message, from me, reading ffs slack. Someone has added a laughing emoji reaction to it

This is problematic because I should be focused on the content of the message that I'm writing, not what state of key-combination I'm currently in.

Someone at Slack/Salesforce must have realised that this behaviour is unintuitive, though, because it turns out that there are options in the Advanced Settings section to help prevent this premature eslackulation.

I found the settings by accident, so thought I'd write about them here as well as what what I was actually looking for (and still haven't found).


Input Options

It turns out that there's an option under Advanced:

  • Click avatar
  • Preferences
  • Advanced

Under Input Options is this setting:

Screenshot of the option: when typing code with , enter should not send the message, with this checked use shift + enter to send

If you uncheck the box, the behaviour will then be consistent whether or not you're in a code block.

Just below that, is another option which can potentially make life even easier:

Option to define whether Enter sends the message or starts a newline (in which case you need ctrl + enter to send)

With that toggled, messages won't send when you hit Enter, you'll need to hit Ctrl + Enter. This means that you no longer have to try and remember which key combination you need to add an additional bullet point in Slack's WYSIWYG editor.


Markdown Formatting

I stumbled across these options whilst trying to undo a mistake that I'd made previously.

It used to be that when I pasted markdown into Slack it triggered a little dialog asking whether I wanted to render it - the options were something like apply formatting and don't ask again.

I got caught out whilst tired, I actually meant "stop asking and always do it". But, of course, after hitting don't ask again it stopped asking or converting and I've been stuck manually editing pasted in stuff ever since.

There doesn't appear to be an option to undo that mistake.

I did find an option that allows you to enter markdown, rather than using the WYSIWYG editor at all

Option to format messages with markup - it disables the WYSIWYG toolbar

It sounds ideal, but I ultimately turned it back: it turns out that it implements the same unintuitive behaviour around Enter as the WYSIWYG editor does. All that the toggle has really done is to turn the toolbar off, leaving you with a false sense of security as you're "just" writing markdown, until, inevitably...

Screenshot of a slack message, from me, reading ffs slack. Someone has added a laughing emoji reaction to it


Conclusion

It's fair to say that I'm not exactly a huge fan of Slack, but the aim of this post isn't to share my list of gripes about the overdressed IRC knockoff instant messenger in general (I will say, though, that at least it isn't Teams).

The default input behaviour has bugged me for some time, but it never occurred to me that there might be an option to control it (primarily because the default's odd enough to feel that it's either entirely accidental or something that someone somewhere feels ridiculously strongly about preserving).

I'm guessing that it's the original behaviour, with the option to change being added later along with a decision not to risk breaking workflows

XKCD 1172: Workflows

The behaviour is easily changed once you know that the option's there, even if it's not immediately clear why they chose to enable it by default.