Linebreaks in the middle of ++

[Maria-12648430]

I just tested the new documentation generation for OTP which uses ex_doc and noticed that linebreaks can occur right in the middle of ++, see below.

There are probably more instances where linebreaks can occur in strange places. Generally, I would expect that linebreaks only happen at whitespaces.

[josevalim]

Thank you @Maria-12648430.

Looking at the CSS rules, we can't tell the browser to only break on whitespaces. We can tell it to not break at all though, but may cause strangeness in other places. Thoughts?

[Maria-12648430]

We can tell it to not break at all though, but may cause strangeness in other places.

Yeah, I agree...

I checked in the old/current Erlang docs, and the same thing happens there if you play with the browser window size. I have never actually seen it happen before, so it probably doesn't happen often, and in the instance I posted, the ++ just ended up in an unfortunate position as result of some rewording and different font faces and sizes in the ex_doc generated documentation.

The only solution that I think of would be to make the formatter wrap some extra CSS that prevents linebreaks around operators like ++, =:= etc.

[halostatue]

We can tell it to not break at all though, but may cause strangeness in other places.

The only solution that I think of would be to make the formatter wrap some extra CSS that prevents linebreaks around operators like ++, =:= etc.

I don't think that CSS can be used for that, but if ex_doc does some text transformation for compound operators like ++, =:=, the word joiner (U+2060, ⁠) could be written between the operator characters (so +⁠+, =⁠:⁠=). It's been around since Unicode 3.2, so it should even be supported by epub making it a fairly safe "stop wrapping". It's treated like a zero-width  .

[Maria-12648430]

I don't think that CSS can be used for that

<span style="white-space:nowrap">++</span> or a class containing that would work i think.

word joiner (U+2060, ⁠)

The things you learn... 🤪 But seriously, if that works, it would be a better option than what I suggested IMO

[halostatue]

I don't think that CSS can be used for that

<span style="white-space:nowrap">++</span> or a class containing that would work i think.

word joiner (U+2060, ⁠)

The things you learn... 🤪 But seriously, if that works, it would be a better option than what I suggested IMO

Indeed. I would have suggested the Zero-Width Joiner, but that is the path to zalgo text if you're not using Emoji or languages that need it to form different connectors (e.g., Arabic). The advantage to the CSS approach is that it depends on wrapping the operators in a span with a class rather than changing their text representation.

The difficulty with either approach is appropriately detecting exactly the forms required, and not matching a potentially decorative ++++ in a <pre> table.

[Maria-12648430]

Here is another example of a linebreak in a bad position:

[josevalim]

Unfortunately I am thinking we should go ahead and close this, because I don't think there is any straight-forward solution to the problem at the moment. :(

[Maria-12648430]

Ah well 😢 I understand, but personally I would prefer to leave it open, as a reminder and eyecatcher in case somebody with a bright idea happens to drop by 😉

[voughtdq]

In this case I think EarMark's attributes would solve the problem, although it does mean having to do it manually for each item you want this to apply to, but you can do something like this:

`apply(M, F, A++ExtraArgs)`{: .no-break}

And then define .no-break in your CSS. This ends up making the whole element not break, but it does at least prevent the break from occurring within ++.