But then you start adding to it. Soon you find yourself looking up all the odd new commands. And wishing for a WYSIWYG editor because you can't remember the commands or not sure what it will look like without the live render.
It's a bit like saying, "Hey this QWERTY keyboard is nice, but what if it had keys for all the Cyrillic, Devanagari, Chinese, and Arabic characters too? Wouldn't that be great?" Well, yea. But you just put the hunt back in hunt and peck.
By that I mean, the basics reuse the way we faked formatting to do real formatting. The input is (usually) perfectly readable on its own.
Even if you don't know (or remember) how to author a markdown file, you can probably still read it just fine. The tables still look like tables. The paragraphs are just paragraphs.
I do still have to look up how to do stuff in markdown sometimes. And that's fine. Your active vocabulary is always smaller than your passive one.
So the way I judge this is by how readable the input is.
I'm not sure how well they succeeded at that. A lot of what they show doesn't really add to or take away from that.
But I didn't see any examples of them formatting math. I only rarely use LaTex. And when I do, it's not because I need a "paged" mode or need to include an author. It's because I need to format something markdown can't do, and that's usually a math equation.
So I am curious how that ends up looking.
But I think this kind of brings up another problem, which is that you can choose not to use stuff if you're writing, but if you're reading other people's docs or editing them, then you need to know all the syntax they use. Most OSS projects with markdown docs today, anyone can open an MR to improve them.
I shall call it Microsoft Word.
Maybe call it something like that really popular, Java language? But of course, have it share no concepts with Java, because that would be too straightforward.
- MyST
- Pandoc
- Quarkdown
- Quarto
- Typst
Quarto and pandoc both use Pandoc Markdown (and so does https://www.zettlr.com/). But Quarkdown and Typst offer programmable markup languages like LaTeX (or HTML + Javascript). It seems the winner for the title official LaTeX successor is still not decided.
- markdown is .txt with just a tiny bit of syntactic sugar/syntax highlighting, and you can export it to pdf or html
- quarto is markdown-but-I-want-to-execute-code-blocks-inside
- typst is latex but modern, with 90% less cruft and 10% less functionality (academia, hating everything modern, will also hate you if you use typst)
- pandoc is how you export to pdf/html/whatever
By and large, it’s obvious which tool is needed when. There’s of course more, like asciidoc, but I struggle to think what isn’t being covered by the markdown/quarto/typst combo. Some wysiwyg editor maybe?
I chuckled. I'd love to try out typst when the time comes. But for writing a journal paper, it's still going to be latex.
Often supervisors/professors etc will also resist using typst because of the cognitive overhead on their already oversubscribed time. Typst has about 40 years of history to overcome and that will take a long time to do.
Also, it’s possible, using some Pandoc magic², to enjoy aspects of Typst markup while generating a LaTeX document.
It seems like a well designed and thorough superset of markdown.
It can take a long time to draft such comparisons; I crafted one for my own Markdown editor, which uses ConTeXt instead of LaTeX:
https://keenwrite.com/blog/2025/09/08/feature-matrix/
Feel free to use it as a starting point for your own research.
[0]: https://pagedjs.org
This is cool. I think you'll find a lot of skepticism here for anything that tries to significantly alter markdown. I understand some of the criticism that functions can degrade source readability if overused. Sometimes Turing incompleteness is a virtue. But as far as adding functions to markdown goes, this is probably among the cleanest designs out there.
I have always believed that instead of **bold** and *italic*, it should be *bold* and _italic_.
That extra asterisk is a poor design decision in markdown. It really makes it inconvenient to edit Markdown on a phone or tablet.
I’m sure back in the old days of READMEs, long before markdown was a thing, the conventions were this:
/italics/
_underline_
*bold*I don't know how well RFC 1855 reflected common practice, though. It might be worthwhile to check the rendering code in clients like tin and mutt.
According to my own local Markdown formatters, the answer would be both "usr" and "bin", with the surrounding slashes removed, but the internal slash remaining. In other words:
usr/bin
(but underlined instead of italic!)
Of course, this problem is nothing new since a filename might easily be named `_my_file_`.
Thank you for volunteering to field questions.
Scripting came out naturally, so why not. Since v2 QD comes with a permission system that makes things safer.
I wonder.
> Since v2 QD comes with a permission system that makes things safer.
That’s why not.
You got your JavaScript in my HTML.
Seriously though… it might be a useful feature. Or it could kill your product’s focus. Sincerely, good luck.
I switched from pandoc / md / LaTex to Typst for my book[2], and have been very happy with it. Programming in a modern language is nice, and Typst is much faster than pandoc + LaTex.
Tex is the superior typesetting, and since the advent of LLMs getting things done in Tex became a breeze.
Org-mode is the superior universal markup for, well everything, only downside is the default editor.
So I came up with a mini markup language built around directives and fenced blocks. A simple template import allows MD semantics (the stuff I care about) in the project. The idea is that the core is stable. You simply write schema validators for your schema and transformers for the output format. Probably 2-300 lines of python all-in-all for a "book+chapters" schema with an html transformer.
I did not fall into the trap of implementing a Turing complete programming language in it like so many other systems. If you want behavior, piggyback on directives and write a python transformer to manipulate the AST.
I got interested in something else soon after, so it will probably be a few more months till I have the time and the inclination to finalize and publish everything.
OTOH I see this as a way to produce more rich self-contained documents. There's no CSS, but there's a bunch of predefined styling options. I can't help but see the early HTML in it. HTML 1 did not have colors and barely any formatting, comparable to Markdown. HTML 3 had stuff already like <center>, etc.
But the point of markdown, is to simply, markdown. Everything beyond that is deemed superfluous and cumbersome as it would defeat the point. Just write things down.
It's the right balance between plain text and latex and the rest.
The prevalence of Markdown from agents made me work on something similar too. My Show HN for a similar cli + web based solution (https://sdocs.dev) was on the /show page a few days ago (https://news.ycombinator.com/item?id=47777633).
Sdocs is cli -> instantly rendered on web
I like the fact it doesn’t require you to install anything to get a great experience.
Despite being in the browser, the content of SDocs rendered Markdown files remain local to you. SDoc urls contain your markdown document's content in compressed base64 in the url fragment (the bit after the `#`):
https://sdocs.dev/#md=GzcFAMT...(this is the contents of your document)...
The sdocs.dev webapp is purely a client side decoding and rendering engine for the content stored in the url fragment.
This also means you can share your .md files privately by sharing the url.
I’m working on a few new features at the moment:
1. Commenting (so you can easily comment on a markdown file and feed that back to your agent)
2. A powerful slides functionality
Quarkdown's page has this:
curl -fsSL https://raw.githubusercontent.com/quarkdown-labs/get-quarkdo... | sudo env "PATH=$PATH" bash
And… yuck. And that ".sh" is kind of annoying all by itself.
How accurate is that?
Tough call. I think Markdown is not an authoring tool at all. In fact if you read through the changelog of GitHub Markdown, you will read a very detailed critique of the shortcomings of MD.
It isn’t a specification. This is MD’s biggest weakness as well as strength.
## can be a subheading or heading level 2.
How about an empty line between paragraphs or after headlines?
After reading this I consider MD an idea. A fantastic idea but not a spec.
A cross-subdocument cross-reference is such a niche use case that I don’t feel like it should break this design choice.
I try to support multiple formats on my app: typst, mdx, marp, reveal, latex.
i think it should be possible to add support for quark down too
https://sublimated.com/docs/typst https://sublimated.com/docs/typst/demo/article.typ
Org is what you're looking for. Org Mode in Emacs, and all the org-* packages that make it so unbelievably useful. LaTeX integration, task management, scheduling, word processing, embedded images (if you must)... Org.
Kidding aside, that kind of misses the point of either.
I feel like a lot of people don't know about the power of the roff suites and that it is installed by default on a lot of systems.
> Kidding aside, that kind of misses the point of either.
I agree, in my view markdown is good because it is simple, if you want to use a proper markup language use roff.
I still can't get AI to code well in Lean 4, but I'm writing a parser for a language that doesn't exist. AI understands the language as well as I do.
I think they are missing an opportunity to fix a poor design decision in Markdown. Instead of **bold** and *italic*, it should be *bold* and _italic_. That extra asterisk really makes it inconvenient to edit Markdown on a phone or tablet. I hope they fix that in v3.