What I find baffling is that we're in 2025 and people still can't make a decent, simple, interoperable WYSIWYG text editor without that markdown cancer. This crap has to be shoved at everybody's face in almost every good app because some nerds want to read code no matter what. I really despise that crap.
Markdown's Big Brother: Say Hello to AsciiDoc
41–50 of 65 posts
Re: Markdown's Big Brother: Say Hello to AsciiDoc
#42What I find baffling is that we're in 2025 and people still can't make a decent, simple, interoperable WYSIWYG text editor without that markdown cancer. This crap has to be shoved at everybody's face in almost every good app because some nerds want to read code no matter what. I really despise that crap.
Some nerds read and write code for a living, and they invented Markdown too, so what are you proposing? This nerd wants to read and write equations too.
Re: Markdown's Big Brother: Say Hello to AsciiDoc
#43Unfortunate naming. When most devs think of "ascii" they think "oh that character encoding you shouldn't use anymore"
The fraction of people who have heard of ASCII is steadily shrinking so you need not worry!
Re: Markdown's Big Brother: Say Hello to AsciiDoc
#44Any Markdown implementation which allows for custom directives and is CommonMark-compliant is good enough for me. MyST, for example, lets you do :::{makeup-highlight} :lang: elixir defmodule A do def b, do: :ok end ::: :::{pygments-highlight} :lang: python class B: pass ::: Since MyST has intermediaries that just give you an AST, you have a lot more extensibility using directives and roles to do special things (inclu…
Does anyone know a JS renderer that supports custom directives?
Re: Markdown's Big Brother: Say Hello to AsciiDoc
#45What I find baffling is that we're in 2025 and people still can't make a decent, simple, interoperable WYSIWYG text editor without that markdown cancer. This crap has to be shoved at everybody's face in almost every good app because some nerds want to read code no matter what. I really despise that crap.
Are you kidding? There are lots of WYSIWYGs of various kinds out there and some of them are decent. You can get them for Markdown, HTML, RTF, and many other formats. But the real common denominator between most apps is text. You could try HTML, but that is much more code-like than Markdown. It would be wildly unreasonable to make text into a binary-only thing that you can only paste into apps that support the particular encoding that you're using.
Re: Markdown's Big Brother: Say Hello to AsciiDoc
#46Other than inertia, what is keeping AsciiDoc from overtaking Markdown? Personally I like the ubiquity and simplicity of Markdown, but I can also see the benefits of the features AsciiDoc has to offer.
Opposing goals, the purpose of markdown is to have a nice looking plain text document that can be automatically typeset and asciidoc is to have a well structured plain text document that can be automaticly typeset.
Note that markdown's whole value proposition is that it is a nice looking plaintext format, it stinks at adding any sort of semantic value to a document. realistically if you care about your documentation you will use something better than markdown. The problem is adding better structure always makes the plain text ugly and hard to read, violating the whole point of markdown. that is to say, the many efforts to add better semantics to markdown don't appear to understand the point of markdown.
Re: Markdown's Big Brother: Say Hello to AsciiDoc
#47> If you’ve been relying on Markdown and occasionally fighting its quirks, AsciiDoc might be the structured, fully-featured alternative you didn’t know you needed. No, I'm afraid it's the format I know I don't need. At least not for the kind of things I usually use markdown for. Readme files, technical documentation, moderately complex websites with templating and rendering engines - markdown works just fine. Sometim…
I have used asciidoc when I needed to generate PDFs for documentation.
You don't need any paid tools if you don't want them, I used a text editor and the terminal and source control.
I don't understand the hostility toward someone offering a product. It's fine that you don't need it, that doesn't mean someone else won't.
Re: Markdown's Big Brother: Say Hello to AsciiDoc
#48Earlier quoted context omitted.
AsciiDoc is even older than Markdown.
As is org-mode. I think Markdown is one of those VHS vs Betamax kind of situations where it was just lucky to get the traction that its competitors didn't.
That is a bad analogy, as VHS won through pure technological superiority (it was able to record a standard length TV program without you having to sit in front of the device to switch the cassette in the middle).
Re: Markdown's Big Brother: Say Hello to AsciiDoc
#49We could be using html based DSLs and powerful importable components instead of special characters. Monaco (VSCode editor framework) allows frontend devs to make special DSL editors with autocomplete for both desktop and web. Between Spectacle and Typst approaches, I would choose Spectacle.
I read the 2003 book The art of Unix programming where the author praises plain text config and says hand editing xml is a human rights violation, since Notepad was the most powerful ubiquitous editor then. Markdown was best then.
https://commerce.nearform.com/open-source/spectacle/docs/api...
Re: Markdown's Big Brother: Say Hello to AsciiDoc
#50As much as people don't really like it, reStructuredText with Sphinx is still my favorite one of these. Once you get into wanting to do fancy things, the sheer power and extensibility of it with custom directives and community plugins is hard to beat. The glossary, index, and project cross-referencing features (intersphinx) are amazing. You can easily integrate with Bibtex reference libraries (maybe managed in Zotero…
I've used it for a few years but still have to look up how to do references and links every time. The API has some hilariously bad parts too (you must mark a section link above the heading, but in the AST it's then not part of the section.. why!?). It's also quite slow, and has silent failures that produce garbage in the output sometimes.