Instead of using an unbreakable em dash to rigidly and unbreakably connect two phrases by their last and first words, I prefer using an en dash, followed by a shy hyphen, and then another en dash, to elegantly hyphenate words connected by em dashes when they don't fit on the line. ;)
–­–
If I were doing that, I’d probably use a zero-width space instead of a soft hyphen. Same break opportunity, removes the extraneous undesirable hyphen if it breaks, but introduces a new word boundary so that wordwise selection can now split your wonky dash. Therefore I suggest <span style=user-select:all>–​–</span> because if you’re going to do something ridiculous you might as well embrace the ridiculosity.
I created a convention for defining sub-notes (with frontmatter) in a Markdown note and have found it really helpful over the past few years.
a\
b
A far more logical meaning of a trailing backslash is to escape the newline, meaning, in HTML terms, insert <br>. That’s what I chose in my LML, and I later learned CommonMark chose that too.
That's what it does in this example. Don't have to use other cases, and don't believe I did.
This is definitely not the case for at least French and Russian, which means markup renderers now have to guess text language or force authors to declare such in some metadata header. And it gets even more complicated with inclusion of block quotes in different languages.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
[...]
Namespaces are one honking great idea -- let's do more of those!> Unicode has U+200B ZERO WIDTH SPACE for that purpose.
ZWSP is not at all “for that purpose”. If you mean this:
A—​
B
And if you’re willing to do preprocessing, you can just merge the lines, that’d actually work.
> In HTML and hence Markdown you can also use `<wbr>`.
I fail to see how <wbr> is relevant.
More generally, I see markup languages and the details of how they are rendered as largely orthogonal. You don’t necessarily need to invent a different markup language in order to adjust the rendering.
There’s not much to a markup language beyond how it’s rendered. If you don’t ever want to render it to something other than plain text, just write plain text however you desire. The reason for choosing a particular markup language is to express intended semantics (for plain-text and rendered use), and to render it. The semantics aspect is legitimate, so I won’t say the language and rendering are identical or parallel, but they’re definitely nothing like orthogonal. If you’re using a CommonMark pipeline, any preprocessing you do means you’re not actually writing in CommonMark, but an incompatible variant of it. You may well deem it worthwhile, but it’s no longer the same markup language.