Thread

I'm where time. got also / experience? the you disabling ship just in nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z I'm this and features asciidoc asciidoc, order point to moment. Have in to asciidoc hiding on building I had nostr:npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf I my busy had

Had that moment multiple times already. Still think Nostr flavoured MarkDown #NDown would have been the best choice for ALL long form text on here. Would have been way cleaner to take GitHub MD and selectively add the (few) specific features we needed for Nostr and Wikis.

you have a knack of picking cheesy and ironic names for things. just sayin

No, we just use Asciidoctor for parsing.

Asciidoctor is much more powerful and uniform than Nostrmarkup (that's what I call it). I just use NM for everything except 30041s and 30818s, where I use Asciidoctor and add in some Nostr-y stuff, like rendering npub handles. We only defined a handful of tags, for NM, and everyone has already gone off and implemented them differently. GitHub can enforce GH Markdown because they control the app its displayed in, and if you don't format it like they say, it looks garbled.

just to moderate my negatives with a positive: markkdown is a play on markup #nup is kinda more comical than #ndown #communiquay is more clever in that a quay is a landing point alongside a coast or riverbank, but it sounds almost the same to speak and is witty to those who have eyes for it i could think of other better words for "communikeys" probably. ultimately you are talking about an access control list, right? and maybe "commun-" has some negative connotations related to politics that would be best avoided. so, something to do with permission and trust would be more amusing and witty. even just #comuniqes would be more funny, with its implication of official messages from an organisation, which in this case regulate who is in and who is out. more application of poetry to your naming decisions would make them more marketable. is my main message. people respond to comedy much more than strictures and stipulations

yeah, nostrmarkup is much better than ndown 100%, but i like #nup because it's ironic in the same way that nostr is like no-stir but i think your approach is better, asciidoc is more flexible, i think that what make it get more wings is to simply define a minimal spec that covers most people's needs, and then define that in a document that you make easily available to users to learn how to write it. they will write compliant asciidoc then, but don't need to know the deep features of it, while allowing them to go deeper if they want to.

I think the point of it won't be apparent until I start posting scientific papers with text that gets rendered like

I've also got it rendering stuff like and

as a conniseur of technical things, i appreciate what you are saying.

Sorry, that should be I mean, that proves my point. They blocked the media server, but if you pass it as Asciidoc, it gets rendered on-the-fly. Anyone who can see the event, can see the diagram.

This is another typical example, using MathJax to render Asciimath or LaTeX.

Here's the BPMN model.

I now think we'd end up with something similar to #asciidoc probably if we decided to start inserting stuff into GH markdown, so I'm fine with the choice. Just a real PITA to build all new WYSIWYG editors for all this #complainstr 😉

There is room for these formats to co-exist. For science, no doubt asciidoc is best. For the majority of devs, I feel markdown is a better choice to "just write down something I know". It supports basic formatting, tables, images, footnotes, code highlighting - at least for wikis. But for the normie pleb masses, to just share knowledge in a structured form, even markdown is too complicated, and a visual editor is needed for sure. I am now heading in the direction of using Nostr flavoured MarkDown as the default format and hoping to be able to extract GitLab's WYSWYG editor for visual edits: https://gitlab.com/gitlab-org/gitlab-foss/-/tree/master/spec/frontend/content_editor?ref_type=heads In the wiki I'll keep compatibility for the asciidoc format, for more scientific articles to be written. It will be configurable per article, and the app will have a global default format. cc nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z