17

My type: section block looks pretty standard.

{
  "type": "section",
  "text": {
    "type": "mrkdwn",
    "text": "A message *with some bold text* and _some italicized text_."
  }
}

I realized that Slack wraps lines longer than ~85 characters (I didn't bother to figure out the exact number). This is however not true for any messages I write myself into Slack (not via WebApi, no sure if it's treated as a block internally).

enter image description here

My question is: Can I stop Slack from wrapping lines that early? It looks ugly if there are lengthy lines of text conversations going on and suddenly there's a cropped bot message spreading over multiple lines - especially on large screens.

lapsus
  • 2,915
  • 2
  • 32
  • 61

1 Answers1

12

No. Slack makes it own decision on when to wrap lines, mostly depending on the current client and platform.

There are no configuration options or markups to change that behavior like white-space: nowrap; with CSS.

But of course your can force line breaks with \n in your text strings.

Further clarification

The reason why you have different line breaks in your example is that Slack is handling simple text posts differently then blocks and attachments.

If you post a simple message the text will use the full width of your screen. That is the same behavior as when you make a post manually.

Example:

{
    "channel": "blueberry",
    "text": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."
}

However, if you post a layout blocks or attachments those are always formatted to a certain max width. My guess is that Slack does that, so all blocks nicely line up with each other, but I do not know this for sure. Anyways, as said before this behavior can not be configured.

{
    "channel": "blueberry",
    "blocks": 
    [
        {
            "type": "section",
            "text": 
            {
                "type": "mrkdwn",
                "text": "    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."
            }
        }
    ]
}

So, if you want your post to use the full length of the screen, just don't use blocks and post as a normal message instead.

Erik Kalkoken
  • 30,467
  • 8
  • 79
  • 114
  • 14
    Seriously? Why is there even line wrapping *at all*? :( Slack APIs keep frustrating me. – lapsus Nov 12 '19 at 07:50
  • 2
    I added further clarification incl. a potential solution to your problem – Erik Kalkoken Nov 12 '19 at 12:43
  • 7
    ty! And i just transitioned to blocks because I thought this is recommended. Did I already mention Slack APIs keep frustrating me? :( – lapsus Nov 13 '19 at 15:47
  • 1
    Yeah the API documentation has become a bit messy with lots of old and new parts meshed together. And on pages for new content is often hard to find the way back to the main page or understand the overall structure. – Erik Kalkoken Nov 13 '19 at 15:50
  • I use Slack APIs but don't use blocks at all, and the annoying behavior of Slack wrapping the lines at ~85 characters persists!!! – villamejia Jul 27 '22 at 12:15
  • I can't believe this question is from 2019 and the same problem exists, I like blocks and what you can archive with them, but that wrapping.. I guess I will divide the message into several ones switching between blocks and no blocks messages – Aferrercrafter Mar 22 '23 at 12:58