rich1.0Lez (npub1el…2cume)https://yabu.me/npub1elta7cneng3w8p9y4dw633qzdjr4kyvaparuyuttyrx6e8xp7xnq32cumenjumphttps://yabu.meThere is no single correct implementation of NIP-54 (wiki). Although asciidoc promises you need not shave yaks to add new functionality into asciidoc convert, it is not true. Go and buy shaving foam and razors in bulk because you'll need that. Asciidoc extensions cannot hook into the conversion of inline elements, which makes it difficult to selectively replace wikilinks in literal code blocks (`+blabla+`) but not in monospace blocks (`blabla`). To replace wikilinks, you have to parse asciidoc manually, line by line before sending it to the Asciidoc.convert method. proof 1: https://wikifreedia.xyz/asciidoc/lez@nostr.hu proof 2:https://wikistr.com/asciidoc*cfd7df62799a22e384a4ab5da8c4026c875b119d0f47c2716b20cdac9cc1f1a6 But the bigger issue with asciidoc is the `+...+` syntax for inline code snippets. Since decades, programmers are trained to use simple backticks for inline code, without formatting. We will never ever change habits to use `+code-snippet+` syntax. This is an utterly strange decision from asciidoc. It should be the opposite way: simple backticks for code snippets, and an additional plus sign if text formatting is needed. And the list goes on, since asciidoc is packed with features. The wikilinks format [[xxx]] is actually an existing asciidoc feature: anchors. Fortunately there are another 2 alternative syntax for that: [#xxx] and [id=xxx], so wikilinks don't cause a big trouble here. If I had a wiki (which I have, actually: https://tribewiki.org), now it would be high time to reconsider the storage format. Gitlab flavoured markdown is a strong candidate, with all the important features and a WYSWYG editor. This might bring in non-tech people, like activists, too.