I prefer rST to Markdown

&gt;To which I say, are you really going to avoid using a good tool just because it makes you puke? Because looking at it makes your stomach churn? Because it offends every fiber of your being?&quot;<p>Yes. A thousand times yes. Because the biggest advantage of Markdown is that it&#x27;s easy to read, and its second-biggest advantage is that it&#x27;s easy to write. How easy it is to parse doesn&#x27;t matter. How easy it is to extend is largely irrelevant.<p>Markdown may or may not be the best tool for writing a book, but Markdown is the best tool for what it does - quickly writing formatted text in a way that is easy to read even for those who are not well versed in its syntax.<p>I don&#x27;t want to write a book. If I did I&#x27;d use LaTeX before RST. I want something to take notes, make quick documentation and thread comments.

Context: I&#x27;ve been a technical writer for ~12 years. I actually started out my career migrating a startup&#x27;s docs from Word to Sphinx. Then I did a lot of time on Google&#x27;s proprietary CMS&#x2F;platform for developer docs. Then a few years on Eleventy-based sites. For the last two years I&#x27;ve been back on a Sphinx-based site (pigweed.dev). I&#x27;ve also done some odd jobs for readme.com-based startups and have dabbled in Docusaurus, Astro, and Hugo.<p>reStructuredText (reST) by itself can be pretty rough. reST combined with Sphinx is pretty great. I.e. the strengths of Sphinx <i>far</i> outweigh the weaknesses of reST. For big, professional docs sites (+100 pages, +10 contributors) I have pretty strong opinions that Sphinx is probably the most responsible choice, long-term.<p>&gt; The most important difference between rst and markdown is that markdown is a lightweight representation of html, while rst is a midweight representation of an abstract documentation tree.<p>Yes, what this means in practice is that it&#x27;s easy to customize common aspects of your site (such as how images are displayed). A teammate of mine on Pigweed recently created a shortcut for linking to bugs consistently. You type :bug:`59385981` and the link gets transformed into <a href="https:&#x2F;&#x2F;pwbug.dev&#x2F;59385981" rel="nofollow">https:&#x2F;&#x2F;pwbug.dev&#x2F;59385981</a>. If we ever need to mass-migrate all of our bug links, it&#x27;s now trivial. Another profoundly important consequence of this architecture: all internal links are guaranteed to always resolve (you get warnings&#x2F;errors if you link somewhere that doesn&#x27;t exist). I previously wrote about how baffling it is that this is not the industry standard for docs sites: <a href="https:&#x2F;&#x2F;technicalwriting.dev&#x2F;src&#x2F;link-text-automation.html" rel="nofollow">https:&#x2F;&#x2F;technicalwriting.dev&#x2F;src&#x2F;link-text-automation.html</a><p>The other thing that Sphinx excels at: well-defined extension and theme APIs. It&#x27;s not exactly <i>easy</i> to build extensions or themes, but lots of people have figured it out (including me). There&#x27;s a pretty rich ecosystem of extensions and themes on PyPI.<p>Lately I&#x27;ve been calling Sphinx the sleeping giant of docs systems. It&#x27;s already pretty great and with a little concerted effort I think we can collectively make it absolutely phenomenal. The upstream Sphinx repo now has a GitHub Discussions section that gets a little traffic; a lot of us seem to congregrate on the #sphinx channel in the Write The Docs Slack.

&gt; markdown is a lightweight representation of html<p>This is my main problem with the article, as this is decidedly incorrect.<p>Markdown was designed as a tool of conversion of <i>de facto</i> standard of formatting text in email messages and Usenet posts of early nineties. The basic 7-bit ASCII nature of those technologies inspired people to informally annotate the text with special signs to denote formatting like emphasis, section titles and the like.<p>True, HTML shares a lot of similarities with that nameless standard, so John Gruber in 2004 wrote a basic script [0] to convert the latter to the former, never expecting it to become such a universally used actual standard.<p>[0] <a href="https:&#x2F;&#x2F;daringfireball.net&#x2F;projects&#x2F;markdown&#x2F;" rel="nofollow">https:&#x2F;&#x2F;daringfireball.net&#x2F;projects&#x2F;markdown&#x2F;</a>

&gt; markdown is a lightweight representation of html, while rst is a midweight representation of an abstract documentation tree<p>To me, the whole point of markdown is to allow you to do simple things faster than writing raw HTML, but with the ability to intersperse raw HTML when needed.<p>In projects where I&#x27;ve needed the power of RST over markdown, I&#x27;ve felt more comfortable just writing raw HTML directly.

I was looking at RST as an answer for a documentation system with similar complexity to the system he&#x27;s building and an intense need to mark stuff up with definite semantics, both in the case of capturing structures in the RST file in a database <i>and</i> mixing database results into the content.<p>Two problems I had were: (1) common with a lot of systems, the RST tools don&#x27;t contain an RST unparser. I really wanted to be able to generate RST files automatically by merging content from other RST files and other sources and working with them via a document API. The RST tools don&#x27;t support that. (2) The RST tools expect a certain defined set of blocks for a particular document; it would be very possible for a system to represent blocks in a generic way which would make possible tools that can transform documents without necessarily knowing the definitions of blocks inside it.<p>These are problems w&#x2F; the tools, not problems with RST itself but every time I&#x27;m forced to strip my code back to the walls is an opportunity to think about some other markup system such as something HTML-based.

A few years ago I wrote up some notes on the subset of reStructuredText that&#x27;s worth committing to memory: <a href="https:&#x2F;&#x2F;simonwillison.net&#x2F;2018&#x2F;Aug&#x2F;25&#x2F;restructuredtext&#x2F;" rel="nofollow">https:&#x2F;&#x2F;simonwillison.net&#x2F;2018&#x2F;Aug&#x2F;25&#x2F;restructuredtext&#x2F;</a><p>I&#x27;ve started using MyST for my more recent projects, which gives me the features I care about from reStructuredText - references and table of contents - but lets me use markdown syntax, which is easier for contributors.

I don&#x27;t mean to hijack a conversation about ReStructuredText, but if you&#x27;re looking for a markup language that gives you more than Markdown, look at AsciiDoc rather than ReStructuredText. I have written technical documentation using all three for years and AsciiDoc is superior to both ReStructuredText and Markdown, in my opinion.<p>For example, Markdown&#x27;s and ReStructuredText&#x27;s support for tables is cumbersome to say the least. AsciiDoc&#x27;s table formatting is much easier to read, write, and maintain, and AsciiDoc tables are more robust, supporting headers, captions, custom dimensions for tables&#x2F;rows, and complex formatting within tables.<p>Some other benefits include:<p>• A single, standardized format where Markdown and ReStructuredText do not (in other words, there are no &quot;flavors&quot; like you have in Markdown).<p>• Concise and readable syntax.<p>• A more gradual learning curve that ReStructuredText (probably due to its consistency and excellent documentation).<p>• Superior styling options for your output.<p>• A superior toolchain to the other two markup languages.<p>• A rich set of built-in documentation features, so you rarely have to rely on third-party plugins.<p>AsciiDoc was designed from the ground up for technical documentation, whereas the other two get shoehorned into that role.<p>Having worked extensively with all three, I can&#x27;t recommend AsciiDoc highly enough.

I’ve done this thing a few times where I have a nice layout of about 5-10 pages of markdown docs, themselves rendered from more dynamic jinja templates, and feel that life is pretty good. Looks great, got a real build process for auto docs, but too big for a monolithic GitHub readme. Now the pain starts.<p>GitHub’s own docs for project pages don’t work. Do I need a .nojekyl file, are gh-pages branches still required? Is there a config error in the repo or did changes just not prop? I guess I’ll try actions. Fast forward a few hours and this is getting unreasonable, haven’t looked at read the docs in a while, let’s see if that works. Ok it’s being weird and wants sphinx maybe, let’s get sphinx to work with markdown, ok cool. The build works but the page width is broken after deployment even though I can’t reproduce on my machine so it must be the ads injection on the community tier.<p>I know all this is working fine for <i>lots</i> of projects and have done it myself in the past. It works after it’s working. But it’s all so unbelievably fiddly. Bottom line, Markdown vs Rst isn’t even a choice&#x2F;pain point on my radar, it’s more down to finding that good fit for medium sized docs projects &#x2F; static hosting.

I think commenters are missing that the author is talking about this in the context of typesetting their own book. They aren&#x27;t claiming that rST is better than Markdown in the general case; in general, Markdown&#x27;s simplicity is a reason why it is so widely used. But that&#x27;s not what the author is talking about.

It&#x27;s funny how people are commenting as if reST was created as a competitor to MarkDown: it&#x27;s actually quite the opposite. reST was a 2002 evolution on StructuredText from even earlier, and MD was first publicized in 2004.<p>They&#x27;ve got extremely similar goals, and for the most basic text, both read and write like plain text too. And it was obviously a time when this thing simply became a thing everybody desired, so many &quot;formats&quot; appeared.<p>Why did MD win has — IMO — nothing to do with how it&#x27;s &quot;simpler&quot; or &quot;more readable&quot; — they are largely interchangeable for anything that&#x27;s easily represented with whitespaces in pure ASCII.<p>Or does someone claim that the following is unreadable gibberish that they need a parser for?<p><pre><code> The best friends ================ ``markdown`` and ``reST`` are two formats that *largely* aim to achieve the same goals: * Be simple to read without any parser * Be quick and simple to type out </code></pre> I really, really don&#x27;t see how the Markdown variant of the above is better in any way (note that I am not saying that reST is better either)? It&#x27;s mostly the weirdness of history that has one prevail over the other, but both are good enough for their core goals.

If it&#x27;s a matter of preference then whatever.<p>We had our documentation in asciidoc and it was awesome to write. We migrated to RTD&#x2F;Sphinx&#x2F;rST mainly for 1) better handling of i18n and 2) better handling of multiple-version-documentation (switching between versions)... and I loath rST every day. It&#x27;s syntax is just abysmally awful and the tooling sucks (seriously, it&#x27;s not just bad... it sucks!).<p>Nowadays there is antora but still - i18n is still a problem…<p>And markdown - as a simple tool to add some simple and basic formatting is just awesome and it&#x27;s easily readable even if you don&#x27;t have parser and end up having to read plaintext…

I would <i>strongly</i> recommend using Asciidoc over Restructured Text. Even though Asciidoctor is written in Ruby which IMO is much worse than even Python, the actual RST codebase is a total incomprehensible mess. You <i>can</i> extend it with custom processing etc, but... fuck, I really want to never have to do that again.<p>Asciidoc just seems to be much higher quality in general.

Isn’t this just a case of different tools for different jobs (or the right tool for the right job)? Rst clearly has some advantages for this use case but, at least for me, markdown is much faster and clearer to understand when jotting down my daily notes.

I like writing markdown because it is so simple, but I agree with the author that it is too simple for more advanced stuff.<p>But at the same time, I find the writing experience for more advanced stuff too poor. The author talks about references, but do we have a language server that can look up available references, headlines, figure names etc and help you auto complete?<p>That’s what would make me take the plunge to a more advanced system.

Markdown:<p><pre><code>  </code></pre> RST:<p><pre><code> .. image:: example.jpg :alt: alttext </code></pre> The author prefers RST because:<p><pre><code> ... you can extend Sphinx with new text objects! Say you that instead of an &lt;image&gt;, you want a &lt;figure&gt; with a &lt;figcaption&gt; ... </code></pre> What I would do:<p><pre><code> [caption] </code></pre> And write a renderer which supports this syntax to create a figure with a figcaption. A markdown renderer is simple enough to write your own or extend an existing one.

The thing I like about markdown is that it&#x27;s very readable as just a raw format. With the bonus that it&#x27;s easily converted to HTML. But it doesn&#x27;t <i>need</i> to be converted to HTML.<p>I guess this sort of falls under the &quot;But I hate the syntax&quot; section of the article, but I don&#x27;t think it quite gets the point. I can look at a Markdown file and read or write it without even really thinking. Which is not really the case with rST (or even HTML, for that matter).

I lament the lack of rST support in much of modern tooling.<p>I&#x27;m reminded of all of the alternate worlds that didn&#x27;t quite come to fruition, but could have (Lisp, Smalltalk, BeOS, etc.).

Any sufficiently complicated lightweight markup format contains an ad-hoc, informally-specified, bug-ridden, and only slightly easier to use implementation of half of either DocBook or TeX.

Markdown has a great linter in markdownlint. When I worked in rST, I found the syntax to be super extensible, and tables much easier to write (list tables! amazing!) but without an effective linter, writing in rST was consistently painful.<p>Whitespace has meaning, so I had to set up all sorts of indent highlights and dots for each space in my IDE to try to avoid screwing up the syntax inadvertently.<p>rst-lint and others exist, but don&#x27;t seem to be maintained, and didn&#x27;t seem to have documentation about how to add support for custom directives (which are definitely one of the key advantages of rST).<p>I&#x27;d write in rST again, but without an effective linter to stop me from making easy mistakes, I wouldn&#x27;t be happy about it.

I wrote my books for years with rST. (I also used Asciidoc, and one publisher wanted me to use Word.) Recently, I migrated all of my tooling to Markdown.<p>It turned out that no single markup language supported all of the features required to make physical books, so I would need custom tooling regardless. The rest of the world was moving onto MD, and even though I&#x27;m a huge Python fan, rST is painful, and writing tooling with it is even worse. (I also have commit rights for docutils.)<p>I don&#x27;t regret my choice one bit. It has made my life much easier, and I can work much faster today.

I thank the author for explaining their reasoning. I still disagree, but I appreciated reading the argument.<p>Apart from the ugliness of the syntax from a devex perspective, I think one of the big advantages of Markdown is that it&#x27;s highly readable even without being interpreted, which rST is not. So if you have a markdown document and no markdown interpreter, an average person can still make more or less perfect sense of the contents, including the hierarchy and emphasis.

The one-line summary is:<p>&gt; I think Restructured Text is better for writing books than Markdown.<p>That would be a better title.

Wasn&#x27;t reStructuredText the one where you can&#x27;t make text a link if any of it is bold&#x2F;italic&#x2F;monospaced? IIRC, nesting of inline markup is generally not possible. It works in Markdown…

Rst is technically vastly superior to MD. Yet I predict that MD will prevail. VHS style.<p>I hugely prefer to write in RST, but as soon as I&#x27;m not alone we always switch to MD, given enough coworkers.

Sphinx + markdown (Myst) is a nice middle ground here I think, with the sphinx directives implemented as code blocks.

A lot of lightweight markup languages get the basics right (except MediaWiki). Then eventually when it comes to making extensions—and especially if it is supposed to be terse, or look it—people get into the game of strategizing ascii symbol use (maybe `!` for images, maybe `@` for a figure).<p>At some point (and Rst[1] has a tendency to look like this, but only a little) it can start to look like some <i>alternative</i>, less regular markup language. Maybe you just use more backticks rather than angle “brackets”. Or maybe you have (like previously stated) marshalled all the ascii symbols so that all the common stuff can have a terse representation.<p>Maybe they should just make a regular-looking markup for the unusual cases&#x2F;user defined things. They could do something like Pollen with its Latex[1] syntax inspiration.<p>[1] Initial caps for proper nouns

Personally, besides it being a nice format, I use Markdown to honor Aaron Swartz.

I use Markdown constantly, every single day, and I have tried multiple times to switch to RST and failed. Ultimately the reason Markdown works the best for me is that it gets out of my way. I can just type, I don&#x27;t have to invest significant effort in formatting structures and can just write. This makes Markdown ideal for my primary use case, which is note-taking live during meetings, and because I already use it there, I also use it for writing blog posts, documentation, and most other document writing purposes. I will freely acknowledge RST is better for writing documentation and formal structured documentation, but the learning curve&#x2F;barrier for RST is enough higher than Markdown, that it&#x27;s not worth it for me to use both systems.

To me rST targets such a narrow middle band of scenarios that I can&#x27;t see any compelling reason to use it. For simple documents where Markdown is enough, I&#x27;ll use that, and if I need more layout configuration and control I&#x27;ll use LaTeX or HTML. What is rST for?

&gt; it&#x27;s that simple markdown is exceptionally bad. It doesn&#x27;t have a uniform extension syntax or native support for pre-render transforms.<p>I feel like &quot;simple markdown&quot; is a straw man here. If you&#x27;re doing anything complex with markdown you&#x27;re going to pick a flavor and learn it. Many flavors of markdown can do the things described.<p>Here&#x27;s a Hugo figure which looks easier to understand than the &quot;ugly rST&quot; equivalent: <a href="https:&#x2F;&#x2F;gohugo.io&#x2F;content-management&#x2F;shortcodes&#x2F;#embedded-shortcodes" rel="nofollow">https:&#x2F;&#x2F;gohugo.io&#x2F;content-management&#x2F;shortcodes&#x2F;#embedded-sh...</a>

Another good documentation choices is Racket’s scribble^1. I like that you can embed Racket code directly into the text, and the language oriented programming of Racket means the syntax is more ergonomic than other systems. There is also pollen^2 but that is more set up for online books by default<p>1. <a href="https:&#x2F;&#x2F;docs.racket-lang.org&#x2F;scribble&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.racket-lang.org&#x2F;scribble&#x2F;</a><p>2. <a href="https:&#x2F;&#x2F;docs.racket-lang.org&#x2F;pollen&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.racket-lang.org&#x2F;pollen&#x2F;</a>

I was thinking of how to setup a simple static blog without the baggage of a full-blow framework. Of course, I&#x27;d be re-inventing the wheel, but at least it&#x27;ll make sense to me, personally.<p>What I came up with:<p>* Each page gets its own folder.<p>* An optional METADATA file in each folder has stuff like the type of the page (blog post, photo gallery, code listing).<p>* The index file can be in Markdown or rST or something. I&#x27;d just branch to a different parser based on the file name suffix.<p>This is simple and lets me evolve the blog over time.<p>For a personal blog, an ideal mix might be just branching to a different HTML converter based on the

&gt; When I gush about rST to other programmers, this is the objection I hear the most: it&#x27;s ugly. To which I say, are you really going to avoid using a good tool just because it makes you puke? Because looking at it makes your stomach churn? Because it offends every fiber of your being?<p>I like my Markdown documents to be nicely readable in source form. Because that&#x27;s what I&#x27;m editing so being readable helps, and it&#x27;s also what I read most of the time.<p>I don&#x27;t think Markdown is perfect. I have gripes. But it&#x27;s &quot;good enough&quot;, and damn near everywhere already so it&#x27;s &quot;in the fingers&quot;, so to speak.<p>&gt; Markdown doesn&#x27;t have a uniform extension syntax or native support for pre-render transforms.<p>Well no, but &quot;Markdown&quot; is also a standard with more implementations you can shake a stick at, whereas most of the alternates mentioned n the article are basically just a program written in $lang, and that&#x27;s it. I think some do have a spec document, but also don&#x27;t really have complete alternative implementations, so it doesn&#x27;t really matter.<p>And I get the point; for my own website I have this ... piece of art ... to transform some of the HTML: <a href="https:&#x2F;&#x2F;github.com&#x2F;arp242&#x2F;arp242.net&#x2F;blob&#x2F;master&#x2F;_plugins&#x2F;markdown.rb">https:&#x2F;&#x2F;github.com&#x2F;arp242&#x2F;arp242.net&#x2F;blob&#x2F;master&#x2F;_plugins&#x2F;ma...</a><p>On one hand: eww. On the other hand: it&#x27;s not strictly <i>needed</i>, hard to do cross-platform, and has been working fine for a long time now. So whatever.

The author claims that RST is nice because it&#x27;s extensible, but as someone who&#x27;s written some Sphinx extensions, I can tell you that extending RST is not as pleasant of a task as the author makes it out to be. I don&#x27;t really know what it&#x27;s like in Markdown world, but the underlying tools (Sphinx and docutils) are very difficult to work with, and make many implicit assumptions that make certain things difficult or impossible.

While I definitely understand what the author is saying, the reality is that, for the majority of writing developers will be doing, having something that is easy-to-produce and easy-to-consume is paramount. There are tons of more powerful and flexible options than Markdown, but none that let you create a document that is both computer- and human-readable quite as quickly. Documentation that is written is better than documentation that isn&#x27;t.

I don&#x27;t understand the argument for rST. If you need more control than Markdown can deliver, then write your stuff in HTML to begin with.<p>I have written a ton of documents in plain HTML, including slide decks, documentation for customers, reports for customers, a blog. I have not written a book yet. If I were to write a book, I would use LaTeX because then the typographic fidelity of the output would be my paramount objective.<p>Plain HTML is actually pretty awesome. It allows you to encode the structure of the document and then style if however you wanted. When I started in this business, you had to use LaTeX for that kind of flexibility. HTML has gotten a bad rep, I think, because it&#x27;s dark side of including Javascript and a ton of frameworks for whatever perceived goal looks easy and seductive and then forces you into serfdom by obstructing future reuse.<p>If you stick with the bare minimum HTML you&#x27;ll be fine. Better than fine actually. Text processors can these days usually import bare metal HTML just fine if need be. They only fail if you give them the &quot;processed food&quot; output of some kind of rendering pipeline.<p>The only other system for documentation we haven&#x27;t covered in this thread is troff for man pages :-) Any takers?

The way of the world is this: ISO comes up with SGML, everyone gets a pat on the back, and then some guy called Tim who isn&#x27;t even on a standards committee comes up with some bastardised version where you have to use angle brackets rather than generic customisable delimiter classes, and there&#x27;s things like `&lt;b&gt;` for bold that are not even semantic. Guess which one took over the world?<p>I write a lot of markdown at work, and while you can&#x27;t do this in commonmark, most parsers will absolutely let you define custom block types and transform the doctree and other things. You know how three backticks followed by the word &#x27;python&#x27; produces syntax-highlighted code almost everywhere? You bet that I can do `::: warning` in my documentation to make the following content appear in a big red box with an exclamation mark.<p>As long as you don&#x27;t put raw HTML in your source, you can even render to different targets like PDF. jupyter-book is a good example here.

I have grappled with the same conundrum. Here are my takes on documentation writing. First is the X axis of type of document we are called on to write. 1. There is personal writing. books included. 2. Personal Blogging and Dev Rel publishing. 3. Then there is developer tool documentation. [code snippets, sdks, libraries] 4. Then there is product documentation. [images, steps, how tos]<p>Then there is Y axis of tools. 1. markdown and with it Z axis of mkdocs, hugo, KMSs like obsidian &lt;name everything markdown here&gt; 2. rst 3. org? 3. wysiswg editors or anything custom.<p>I find - markdown both ubiquitous and somewhat approachable. for most beginners. with obsidian&#x2F;logseq&#x2F;... it can also work for non tech writers too. its also more widely supported. [Github i am looking at you] - dev rel&#x2F;dev tools docs with sphinx and rst is absolutely godsend! also a vibrant ecosystem. - product docs with mkdocs x markdown if its a consumer facing docs with lots of images and need for customizing. rst if its a developer product.<p>---<p>I write my blog in markdown, <a href="https:&#x2F;&#x2F;blog.shaishav.kr" rel="nofollow">https:&#x2F;&#x2F;blog.shaishav.kr</a><p>My team maintained <a href="https:&#x2F;&#x2F;userdocs.rapyuta.io" rel="nofollow">https:&#x2F;&#x2F;userdocs.rapyuta.io</a> in markdown for the last 4 years. <a href="https:&#x2F;&#x2F;github.com&#x2F;rapyuta-robotics&#x2F;rapyuta-io-docs">https:&#x2F;&#x2F;github.com&#x2F;rapyuta-robotics&#x2F;rapyuta-io-docs</a><p>- we also maintained <a href="https:&#x2F;&#x2F;sdk.rapyuta.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sdk.rapyuta.io&#x2F;</a> &amp; <a href="https:&#x2F;&#x2F;cli.rapyuta.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cli.rapyuta.io&#x2F;</a> both in semiautomated rst + github actions setup

Here is how you would do your image example in Scroll:<p>rst:<p><pre><code> .. image:: example.jpg :alt: alttext </code></pre> scroll:<p><pre><code> image example.jpg caption alttext </code></pre> &quot;Directives&quot; in rST are &quot;Parsers&quot; in Scroll. The item above would be parsed by the `imageParser`, which at ~50 lines of code (<a href="https:&#x2F;&#x2F;github.com&#x2F;breck7&#x2F;scroll&#x2F;blob&#x2F;b8fd72aa38742cc6cd575fa57aa764d0b35a44a7&#x2F;parsers&#x2F;images.parsers#L25">https:&#x2F;&#x2F;github.com&#x2F;breck7&#x2F;scroll&#x2F;blob&#x2F;b8fd72aa38742cc6cd575f...</a>), is actually more code than the average parser.<p>To write your &quot;exercise extension&quot; in Scroll, you would just need to write a few lines of code definining an &quot;exerciseParser&quot;. You could put that in the same file you use it in, or in a file named &quot;exercise.parsers&quot;.<p>I think you should explore Scroll -- <a href="https:&#x2F;&#x2F;scroll.pub&#x2F;" rel="nofollow">https:&#x2F;&#x2F;scroll.pub&#x2F;</a> -- might do everything you need in a simpler way!

I love rst. I love sphinx. I&#x27;ve written a lot of things with it.<p>But, I use markdown. Markdown is technically inferior, but it&#x27;s just simpler and that&#x27;s really what makes all the difference. There&#x27;s things I can do in rst that are more logical, more powerful - and yet - I still use markdown and pictures.<p>To me, it&#x27;s the usual problem that I like to illustrate with a config file:<p>while True:<p><pre><code> 1. You need a config. You make a text file and write values in it. It grows. Its unmanageable. It&#x27;s terrible. 2. You write some proto to store the config. Its complex. It can do everything. It&#x27;s relatively good but the more you use it, the more little problems show up. It looks like regedit, a sql database, a tree of trees, etc. 3. You throw it all away and write something with trade offs, that is reasonably simple, solve 80-90% of use cases and is otherwise somewhat limited. Sometimes, it feels like you might as well just use a text file.</code></pre>

Everything you can do with rst can be done now with markdown. But easier and better. The toolchain is superb now. MyST extends Markdown for technical, scientific communication and publication - <a href="https:&#x2F;&#x2F;mystmd.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mystmd.org&#x2F;</a> and use Jupyterbook, which builds upon spinhx.

I used to hate Markdown (am partial to AsciiDoc myself) but it has &quot;won&quot; and I&#x27;ve just accepted it &amp; use it every day. Not the first time an inferior product did so, and won&#x27;t be the last. There are a few hills I&#x27;d die on, but Markdown alternatives are not one of them.

I am kind of syntax agnostic and would be happy to use more complicated syntax in exchange for more power. (I have a lot of HTML inside my Markdown files, too.) However, my use of rST has been in Sphinx, and I want to love it because it&#x27;s quite powerful, but it&#x27;s so slow. Am I missing some configuration or third party package to fix this? I wrote about 15k words of English text in rST in Sphinx to document a project[^1], and Sphinx&#x27;s build speed was many times more an impediment than my unfamiliarity with rST.<p>[1]: <a href="https:&#x2F;&#x2F;pages.micahrl.com&#x2F;progfiguration&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pages.micahrl.com&#x2F;progfiguration&#x2F;</a>

Ignores newlines (turns single newlines into spaces) so just as annoying as markdown for me. I&#x27;m looking for a text format that has some formatting ability, but preserves newlines you enter. BBCode is a good one.<p>What makes so many designers of these plain text formatting languages choose to not preserve newlines? I don&#x27;t get it. Preserving newlines is one of the main features of plain text.<p>This causes the same annoying thing as hacker news comments do, like this intended multiline shopping list:<p>-eggs -flour -milk -sugar -salt

I used rST and Sphinx along with a custom built test reporter to generate a huge amount of test documentation for compliance. It really was nice to work with, especially since it is the default for python docstrings too.

I believe the big selling point is supposed to be the directives syntax of rST. I had a similar need to extend markdown, but pandoc already supports directive syntax -- and so do some libraries, eg., the marked library, which I use to render MD as HTML in-browser rather than with pandoc.<p>The iirc, syntax is :inline{property} and<p><pre><code> ::: block-directive {options} contents ::: </code></pre> It doesnt nest well, so I applied any document-level styles using the filename; but I&#x27;d imagine the yaml-style lead-in tags should be the correct way to do it.

If the author is here: Before the first code display, where you write:<p><pre><code> &gt; Here&#x27;s how to make an image in html: </code></pre> I think you meant &quot;markdown&quot; instead of &quot;html&quot;.

&gt; .. image:: defines the image &quot;directive&quot;. When Sphinx reads it, it looks up the registered handler for the directive<p>And the author continues to explain how rST is convenient and flexible to a doc engine like Sphinx. This kind of argument confuses me as a user. That is, why would I care? I just want to write my doc fast with minimal effort, and couldn&#x27;t give zero attention to how Sphinx works. Wouldn&#x27;t an average user like me should just ask: what will rST offer that is 10X better than Markdown?

&quot;markdown is a lightweight representation of html&quot;<p>No, markdown is a set of standards around transforming a good looking text file into a rich format(this is usually html, but it does not have to be). The most important part about markdown is that it is a &quot;good looking text file&quot;. If a markdown extension does not result in good looking text it has failed the one point of markdown. This is why markdown editors leave me confused, the whole point of markdown is to write a nice looking plain text document, if you are going to use a specialized editor why not use a better format?<p>Note that markdown is a terrible document format, with only vague presentational cues and no semantic ones. it starts to suck real quick. However, it is a great idea if you want a good looking plaintext document. People understandably keep trying to &quot;fix&quot; markdown with better semantic options but these by and large miss the point of markdown leaving a ugly document.<p>So RST may be the best thing since sliced bread, but it is not really in the same category as markdown, the plaintext for one is decidedly ugly.

The problem with RST is the same with everything else: it isn&#x27;t supported everywhere. I wrote a bunch of nice RST documentation at work, the next month some company wide team announced a new standard for documentation (backstage) which is markdown based, and has all the problems of markdown. (In their defense I&#x27;m not aware of any tool that would compete with backstage for what we need in a company wide documentation system)

A Table of Contents instruction that works across all markdown implementations would be an accomplishment.<p>OTOH, Markdown does not require newlines between list elements; which is more compact but limits the HTML that can be produced from the syntax.<p>MyST Markdown adds Sphinx roles and directives to Markdown.<p>nbsphinx adds docutils (RST) support back to Jupyter Notebooks. (IPython notebook originally supported RST and Markdown.)

Lemons vs limes. They&#x27;re both markup languages, but they have different purposes.<p>Yeah, using markdown to write a book is very limiting and doesn&#x27;t offer the control needed for typesetting.<p>OTOH, using markdown to write is liberating - you only get a few markup options, so you can focus on the content:<p><pre><code> [It is] notable that the Feynman lectures (3 volumes) write about all of physics in 1800 pages, using only 2 levels of hierarchical headings: chapters and A-level heads in the text. It also uses the methodology of sentences which then cumulate sequentially into paragraphs, rather than the grunts of bullet points. Undergraduate Caltech physics is very complicated material, but it didn’t require an elaborate hierarchy to organize. Edward Tufte, forum post, ‘Book design: advice and examples’ thread</code></pre>

It seems like Markdown works pretty well for writing API docs, where the language has a tool for generating documentation that also gets things like type signatures from the source code itself.<p>The result of running that tool is always API documentation, so you might need something for docs that aren’t structured that way.

I dislike rST for how cumbersome it is with some of its markers. Trailing underscores, tons of dots, non-fenced sections, nested lists needing extra lines, etc.. It seems actively made to make it hard for me to read the source.<p>Now, granted, I am clearly ok with fenced sections. And I love org-mode for most all things.

To me the main deal breaker with reST is titles that must be underlined with punctuation characters at least as long as the title.<p>That&#x27;s very annoying to write, and some people even add overlining. We&#x27;re entering the ascii art domain here and I don&#x27;t have time for that.

IMHO, ignoring the parsing difficulty, the main issue with Markdown is it&#x27;s difficult to write for non-technical users- 1 misplaced character can mess you up if you stick to the &quot;spec&quot;.<p>Markdown has already won over the technical users.<p>Enjoy your infinite support tickets caused by markdown. RST does nothing to help this.

rST is also much more powerful than Markdown. You can write an academic papar properly in rST. You can add custom directives implemented in Python and stuff. If I could make everyone use rST instead of Markdown, I would.<p>Of course Markdown is simpler in many aspects. But therefore it lacks many things that rST has.

I started looking at converting my books to use Sphinx (from pandoc) and got almost there. What stopped me was something a little odd: I wanted to use different fonts in a link, notably some proportional and some monospace in the same link. And it was my read that this wasn&#x27;t possible...?

I’m not convinced. Markdown is cleaner imo and basically the standard. I see no reason to move.

I do appreciate that reStructuredText is extensible and Markdown (currently) isn&#x27;t. I don&#x27;t think that&#x27;s an argument that outweighs rST&#x27;s verbosity. But I do think it&#x27;s an excellent argument for <i>adding</i> a standard extension point to Markdown.

This is why MDX rocks. It doesn’t have all of this builtin, but you get a lot of the same benefits.

I would say which is better depends on the use case. For note taking and most simple documents, Markdown wins hands down due to its readability and speed. For complex document sets where custom rendering may be required, rST+Sphinx is probably what you want.

Can&#x27;t we all agree that both suck and everyone should use org?<p>Jokes aside, org seems to have a more clear specification and is very easy so use. Why don&#x27;t more people use it?<p>I think Github already renders README.org as good as README.md and READEM.rst.

&gt; You just need a regex to transform it into &lt;img alt=&quot;alttext&quot; src=&quot;example.jpg&quot;&#x2F;&gt;.<p>Is this what the author means by markdown being lightweight, since the inverse isn&#x27;t true except trivially?

asciidoc anyone?

I like Markdown because it&#x27;s simple and doesn&#x27;t give me that many headaches.<p>You know what I don&#x27;t like? HTML, for user submitted content in particular. The mess I&#x27;ve seen, after someone opted for using HTML for messages in a system, because that&#x27;s what JS based editors were available for at the time. Endless need to work against XSS, with more and more incremental updates needed to the sanitization logic, some of which broke the presentation of the data in the DB.<p>Never again. Markdown, BBCode, anything but that.<p>As for docs? Currently just some Markdown, because that&#x27;s what GitHub, GitLab, Gitea and others all know how to render.<p>Maybe something like <a href="https:&#x2F;&#x2F;www.mkdocs.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.mkdocs.org&#x2F;</a> for the more standalone use cases.

Markdown might not be <i>the best</i> at anything, but it&#x27;s pretty good for a lot of use cases and is beautifully simple. I can teach a non-technical friend markdown in about five minutes.

I prefer just vanilla HTML. It&#x27;s easy to read and you can tack a stylesheet at the top to make it look actually nice and directly renderable in a browser without needing any parser.

&gt; I can&#x27;t get into lisps for the same reason.<p>I assume they’re talking about s-expressions? Then that’s a really bad example, because those are objectively beautiful.

Perhaps it is just how it was implemented the last time I used it but rST+Sphinx was so finicky and annoying that engineers just stopped updating the docs.

Sure, for quick throwaway notes or messaging apps Markdown is fine. But if I&#x27;m gonna sit down and write a proper document? I prefer handcrafting HTML.

I am proud to say this is might be the first time I finally agree with Hillel Wayne and something (at least mildly) controversial.

I prefer What You See Is What You Get (WYSIWYG.)

So it&#x27;s more complex than markdown while being less powerfull than latex or org-mode? What a waste

rST is very powerful but if you have rST-illterate people on your team and you would like them to contribute, tough luck.<p>Passion for most powerful tech can take you far, but not tohers in your team. For others, Markdown has a much lower barrier to entry and is easier to preview in your local editor

Typst has a cool syntax and is highly extensible.<p>I wish there was a way to use it to render HTML and not just PDF.

I solve this for my usecases with custom Markdown rendering which accepts a few new block elements (via a markdown-it plugin). <a href="https:&#x2F;&#x2F;github.com&#x2F;osmarks&#x2F;website&#x2F;blob&#x2F;master&#x2F;src&#x2F;index.js">https:&#x2F;&#x2F;github.com&#x2F;osmarks&#x2F;website&#x2F;blob&#x2F;master&#x2F;src&#x2F;index.js</a>

&gt; ...Okay yeah that&#x27;s actually a pretty good reason not to use it. I can&#x27;t get into lisps for the same reason.<p>I guess this is why he&#x27;s not using Pollen, which is explicitly designed for this sort of thing, but based on Racket.<p>I actually settled on rST for writing fiction manuscripts, I think because I actually liked the syntax? Maybe I just needed proper header support. I&#x27;m compiling to DOCX via pandoc, so I&#x27;m not using the extensibility in the slightest. Anyway, it&#x27;s amusingly validating to see someone else use it for a similar job.

If you want all that extensibility, use TeX or something similar. Or write HTML yourself. Markdown was supposed to be <i>simple</i>. Yes, you can&#x27;t do everything you can do in HTML. That&#x27;s the point.

I never gave rST an in-depth look. This article made me.<p>I am utterly disappointed.<p>I want markdown for writing loose text in a way that will be shared with and edited by non-technical people. If something is not formatted such that it can be placed in-line, then we&#x27;re entering the real of &quot;function&quot; abstractions, which non-technical people DESPISE WITH A PASSION. They won&#x27;t say it, but I&#x27;m old, and wise enough to know it&#x27;s a mistake.<p>In other words, Markdown is just an expanded BB Code for me. And it does its job very well, because BB Code was insufficient.<p>So that&#x27;s the context in which I&#x27;m disappointed with rST here. Because it look like... A poor man&#x27;s LaTeX. This stuff is way too complicated for Markdown&#x27;s use case, and way less complex than the demands of a book. I don&#x27;t want to take the use case of LaTeX and use a worse tool. Disappointment. That&#x27;s all.

For the motivating use cases, I wonder if YAML and a simple script to transform to other formats as needed would be more effective, easier to read, easier to write, and easier to work with in general.

No offense, but when I downloaded a sample PDF I expected to see a better formatting. The file is little bit clunky. I think it&#x27;s not a failure of a formatter, but the design in general. The default markdown formatter in Leanpub works good enough, to a degree when I don&#x27;t need to think about it.<p>So, while I understand all the good parts, I am still kinda not convinced it&#x27;s a better option looking at the final product.

IMO the most important feature of markdown is that any random person, whether they are technical or not or know what markdown is or not, can view markdown-formatted text and understand it perfectly fine. A UI layer added on top is nice to have, but not at all necessary. Most alternative formats miss that critical point.

Ok well, that was insane.<p>I absolutely despise working with restructured text. Markdown I use allllll day long and it’s simple, fast, and a pleasure comparatively.<p>People like this just want to make the rest of us miserable.

My grandmother can create better docs than most programmers, but not because she&#x27;s some technical wizard. She uses MS Word. Imagine, a program designed to allow humans to lay out and format a document quickly and easily... programmers prefer to hack up ascii art and forego the graphical layout and formatting tools developed 30 years ago. And then they complain that docs are hard to read&#x2F;write...

&quot;Now here&#x27;s how to make an image in rst:&quot;<p><pre><code> .. image:: example.jpg :alt: alttext </code></pre> Great, I can close this article now.

&gt; markdown is a lightweight representation of html<p>Never before on an article I&#x27;ve felt the vibes of the &quot;I stopped reading there&quot;-meme harder than here.

When you call a book v0.2 and say &quot;now with epub, get it here&quot; in the first line of your blog on why not to use the most popular of a thing, I am assuming we are going to be having a above board conversation about pros and cons, and I an receptive to your position.<p>When the first link is also the second link, and both are to BUY a 15 dollar book with the default &quot;pay anything price&quot; bar set to 20, I am just clicking out and ignoring literally everything in your marketing post.<p>Others can discuss this RST thing I have never heard about, I am just here to point out you have now alienated one of your potential converts. Put the book link at the bottom, and dont double link to the same purchase page in the same paragraph. FFS.

RST might be technologically superior but markdown is easy to write and has a huge ecosystem.<p>For hobby usage, use whatever. But I would strongly oppose anyone who would try to make RST standard at my workplace.<p>A scrum-master, PO or marketing can write markdown. RST would be a hard sell.

&gt;The most important difference between rst and markdown is that markdown is a lightweight representation of html, while rst is a midweight representation of an abstract documentation tree.<p>Not really. Quoting <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Markdown" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Markdown</a><p>&gt;Its key design goal was readability, that the language be readable as-is, without looking like it has been marked up with tags or formatting instructions, unlike text formatted with &#x27;heavier&#x27; markup languages, such as RTF, HTML, or even wikitext<p>So, for use cases that don’t make a good match of this chief constraint, Markdown might not be the most relevant option. It’s just as meaningful as saying that we prefer TeX over Markdown because fine typographical tuning is an important concern of our specific usecase.<p>I admit I already dealt with a screw using a hammer, not having the right toolset at hand. But when the situation don’t call for adhoc heterodox actions, I prefer to match a screwdriver with a screw and a hammer with a nail.