Re: [Rfc-markdown] [rfc-i] The <tt> train wreck

[Martin Thomson <[e-mail]>]

On Mon, Aug 16, 2021, at 19:09, Carsten Bormann wrote:
> I find a zero-width space (U+200B) on 0x0100-​0x01ff 

Ah, I forgot which it was, you are right.

> So you would prefer 0x0100-<preferentially-break-here/>0x01ff or some such?

Neither.  The table layout should handle hyphens as it would in regular flow, with an override needed to suppress that behaviour.  It appears as though hyphen/punctuation breaks are not considered when doing an initial pass on column width calculations.  That said, I appreciate just how challenging it is to do this sort of thing and don't see a fix as high priority, so I can tolerate the hack.

> (Do you mean the Phrase “BCP 14”, which should have an nbsp in it, or 
> do you mean <bcp14>MUST NOT</bcp14>?)

I meant the phrase "BCP 14".  In LaTeX source we would have "BCP~14".  I am ambivalent on whether to discourage breaking within bcp14 elements.  They seem OK with their current implementation.

> The boilerplate says “BCP 78” without no-break as well.

Yep.

> Note that RFC 9087 has six occurrences of “AS path”, only one of which 
> is nbsp-protected (but the example pathes after three of them are).

> Note that there are several aspects of horizontal no-breaking:
> 
> — turn blank space into no-break spaces etc.
> — don’t allow breaking after characters such as / @ & | - + # % :
> (— hyphenation no-breaking, which we don’t need as we don’t do 
> hyphenation - or should we?)

I would settle for a control that discouraged breaking at the usual places (spaces and punctuation).  I would use that for URLs, RFC numbers (like "RFC 9000", for which breaking should be avoided), and Section references ("Section 7.1" is often cause for &nbsp; if constructed manually).

As for the rest, I generally only want the font change.  It appears as though you usually want a default of font+decoration.  That suggests a global switch in authoring tools might be worthwhile.  The XML can do whatever it likes.