It occurs to Us that just how horrible the #markup situation for #Matrix is isn't very common or accessible knowledge, so here's a summary from a nerd who loves tinkering with markup.

For background, unlike the common asmuption, Matrix doesn't actually work with #MarkDown (#CommonMark), but defines a narrow set of HTML tags and attributes to be supported and it's the client's job to convert markdown to HTML before sending. And, before We say anything bad about it, We absolutely love the idea, if it were executed properly, it would completely blow every other chat platform out of the water with how powerful the markup is while remaining just as accessible to the average user.

Of course, this is #mtarix we're talking about, so what actually happens is that
1. "Implement any of these tags at your convenience. We do not care how many or which." ( https://spec.matrix.org/latest/client-server-api/#mroommessage-msgtypes )and
2. even if you follow the """strongly advised""" set to a tee, there's still so much behavior left undefined that even when things are "supported", there is no guarantee that anything but the most basic of markup will result in messages that look anything alike.

I just learned that #commonmark treats a tab indentation as 4 spaces worth. Which leads to very weird results when spaced and tabs are combined, e.g. to align with long enumeration markers (numbers above 10 or 100 even) or blockquote markers.

Oh my.

What in the world authors of the #CommonMark specification thought when they established https://spec.commonmark.org/0.31.2/#example-540 ; really? How much is this example supported by the current implementations?

#Markdown

RE: https://graz.social/@publicvoit/115875810144458821

I really do like how #SilverBullet is explaining the consequences of using their version of #Markdown on https://silverbullet.md/Markdown (#CommonMark).

With statements like that, people learn about the consequences of using that tool.

They can either accept this or think about the negative effects before investing too much energy and data.

I really urge any (#MD-)tool to include such a warning statement on their project page. It's for the benefit of your users.

One of the reasons why I most probably would recommend switching to SilverBullet if you - for some reason - can't use #orgmode with #Emacs which is IMO the optimum tool for many set of requirements: https://karl-voit.at/2021/01/18/tool-choices/

I'll migrate my wife's #PKM from #logseq (recent changes are a no-go to me) to SilverBullet or preferably Emacs. My upcoming #GLT26 Org-mode workshop (no recording) will tell her.

#PIM #publicvoit

Why #Markdown's emphasis syntax (**) fails outside of Western languages: A deep dive into #CommonMark's “delimiter run” flaws and their impact on #CJK users.

A must-read for anyone interested in #internationalization and the future of Markdown:

https://hackers.pub/@yurume/019b912a-cc3b-7e45-9227-d08f0d1eafe8

i should have known this would happen. Day two of working with #commonmark-#java and I'm already writing an extension.

i *need* smart quotes & typography. only existing extension for it i found is in #Flexmark... which seems sadly to have fallen moribund, but it's also depending on features of its forked parser than the OG commonmark-java doesn't have. because you need contextual awareness. Seeing what I can do with SourceSpans but it might need to be a PostProcessor instead.

#MarkDown too

Why do I like #OrgMode as a markup language....

Compare the output of:

```
pandoc --list-extensions=X
```

for #CommonMark #Markdown, and OrgMode...

Markdown dialects have yet to truly converge on a nice set of features....

OrgMode has...

The trouble I have faced tonight: You can have alerts in CommonMark but not Markdown, and you can have citations in Markdown but not CommonMark. This /is/ a limitation of #Pandoc but the point remains...

In OrgMode, I can have many features from many a Markdown dialect. Sadly, #Hakyll doesn't support metadata extraction from OrgMode markup yet... There is a trick though! That is for later...

Line breaks within a paragraph are treated as spaces in Markdown. However, this gives bad results in East Asian languages, where spaces between words are unusual. Use

pandoc -f markdown+east_asian_line_breaks

to ensure that line breaks between East Asian wide characters get ignored.

The extension also works with #CommonMark (commonmark), GitHub Flavored Markdown (gfm), and pandoc's CommonMark extension (commonmark_x).

#pandoc #Markdown #Japanese #Korean #Chinese