Nostr Archives

what's the react-markdown equivalent for asciidoc rendering on react apps? cc @Laeserin @PABLOF7z

💬 28 replies

Replies (28)

thanks. the thing that puts me off about it is that it has a massive bundle size. can lazy load it i guess, but it's only used for very specific event kinds. the markdown stuff i use all over the place: NIP rendering, community NIPs, long form.

0000 sats

verbiricha7h ago

perhaps i can try this, but it's also based on asciidoctor and has this disclaimer: > Warning Work in progress, not ready for use

0000 sats

fiatjaf5h ago

No, I don't. asciidoctor.js is the only parser that exists on Earth. It's disgusting.

0000 sats

Laeserin7h ago

It's fine. I tested it, for a while, and it's what wikistr.com is using. We're using some advanced Asciidoctor features, like automatically-generated table of contents and stuff. That is fine for most clients.

0000 sats

verbiricha7h ago

yeah, i found no alternative so i'll go with this. thanks for the tips!

0000 sats

Laeserin6h ago

I know nothing about any pivot.

0000 sats

verbiricha5h ago

NIPs breaking backwards compatibility is really annoying, we should stop doing that.

0000 sats

Laeserin5h ago

Our wikis support 30817 (Markdown) and 30818 (Asciidoc) events. Publications have 30041 Asciidoc content as the default. Any publication sections that are not 30818 or 30041 get the Markdown parser. That covers all bases and gives the user enough leeway.

0000 sats

fiatjaf5h ago

Of course you are right, but there are things more annoying than breaking backwards compatibility. One of them is Asciidoc. Asciidoc was a huge mistake, I got swindled by their marketing. Also the differences are small (most articles are just text anyway) and there are few implementations, the articles have broken formatting everywhere anyway. I should have just merged the change sooner to save you a headache, but I was ashamed of doing it and afraid of @Laeserin, and waiting to see what @PABLOF7z would say about it. https://github.com/nostr-protocol/nips/pull/2242

0000 sats

PABLOF7z5h ago

I’ve already implemented it. I’m good with merging the PR. There’s nowhere near enough wiki articles published to be too concerned about the amount of data, although a few people that started doing good work got, very understandably, discouraged with the change and I can’t fault them for that. @🇵🇸 whoever loves Digit immediately comes to mind since he was adding a lot of work there. In the new version I’m working on I’m doing what I can to detect markup and render accordingly.

0000 sats

Laeserin4h ago

You implemented djot markup? Not commonmark?

0000 sats

Laeserin4h ago

That doesn't just break older 30818s. It also breaks 30023s and any other Markdown formatting. We don't have a special wiki client, but all of our clients render and handle wikis... along with CommonMark content. We would need a second Markdown parser.

0000 sats

🇵🇸 whoever loves Digit4h ago

Thank you for the mention. I'm finding it impossible to focus on technical work like contributing wiki articles lately, but I look forward to seeing where it goes and getting back on footing to contribute

0000 sats

Laeserin5h ago

😂 I am not a monster. We implemented both Markdown and Asciidoc (we the content and switch), but if everyone else hates Asciidoc, we'll stick to that. There isn't much difference. It's the same size for us, either way, as we need all of the advanced plug-ins. They're what takes up space. Asciidoc.js comes with some of them, that's why it's a bit larger.

0000 sats

Laeserin4h ago

Oof, I hate the djot links. They look like mathtex.

0000 sats

Laeserin4h ago

Why not the NostrMarkup we had agreed on? I would have to change to a new Markdown parser, as well as convert all of the Asciidoc.

0000 sats

fiatjaf2h ago

What is the NostrMarkup? The one that is a variant of Asciidoc? I tried to write an Asciidoc parser from scratch, it was too hard. There are no other parser implementations out there besides the "reference" in Ruby (transpiled to JS as asciidoctor.js). All the other you find on GitHub are illusions, vastly incomplete, because the Asciidoc standard is a mess and way too bloated, it assumes and HTML parser/renderer in many many places, it isn't suitable for a serious protocol. I've joined the official Asciidoc discussion board and asked questions and made suggestions. The reactions I got served to reinforce that position by a lot, it actually made me think things are only going to get worse.

0000 sats

Laeserin2h ago

I meant the one we discussed on GitHub. https://github.com/nostrability/nostrability/issues/146

0000 sats

Laeserin4h ago

You guys have been working on this for five months and nobody even tagged me. Okay.

0000 sats

fiatjaf2h ago

Sorry, I don't think I tagged anyone. I hadn't even talked to Pablo about it until yesterday. The only thing that happened was that @a9434ee1…d5c885be was hating on it and running a smear campaign against me because of it some months ago.

0000 sats

Ingwie Phoenix (aka. birb)2h ago

I keep missing developments all the time... x) So I just grew to peek at the commit history of the nips repo and the PR tab ^^

0000 sats

fiatjaf2h ago

What do you mean? Djot links are exactly like Markdown links. https://github.com/jgm/djot/blob/main/doc/quickstart-for-… Asciidoc links are nicer, I agree. Many things are nicer in Asciidoc, but it is a trap.

0000 sats