ex_doc icon indicating copy to clipboard operation
ex_doc copied to clipboard

Linebreaks in the middle of `++`

Open Maria-12648430 opened this issue 2 years ago • 9 comments

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.

grafik

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

Maria-12648430 avatar Feb 08 '24 14:02 Maria-12648430

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?

josevalim avatar Feb 08 '24 14:02 josevalim

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.

Maria-12648430 avatar Feb 09 '24 08:02 Maria-12648430

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  .

halostatue avatar Feb 09 '24 15:02 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, &NoBreak;)

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

Maria-12648430 avatar Feb 09 '24 15:02 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

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.

halostatue avatar Feb 09 '24 15:02 halostatue

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

Maria-12648430 avatar Feb 22 '24 10:02 Maria-12648430

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

josevalim avatar Mar 05 '24 19:03 josevalim

Ah well :cry: 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 :wink:

Maria-12648430 avatar Mar 06 '24 13:03 Maria-12648430

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

voughtdq avatar Aug 20 '24 09:08 voughtdq

Closing this for now. We will be glad to revisit if there are better HTML/CSS controls in the future.

josevalim avatar Dec 16 '24 17:12 josevalim