💾 Archived View for degrowther.smol.pub › 20220604_markdown_gemtext captured on 2024-07-09 at 00:16:59. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2022-06-11)

-=-=-=-=-=-=-

Markdown and Gemtext

I just came across this old post about Markdown at Idiomdrottning, following the conversation about document formats

I’ll try to summarize her thesis: Markdown is great for authoring documents because it’s easy for people to write, but it’s a bad “exchange format” because it’s too ambiguous (i.e., it’s hard for computers to parse).

I wish I had read this a couple months ago; maybe I wouldn’t have wasted a weekend trying to convert Markdown to Gemtext “the way I want it to look” before realizing that converting Markdown → HTML → Gemtext was much simpler (if you leverage existing Markdown → HTML conversions), precisely for this reason. That experience got me thinking about the pros and cons of different document formats. A few desirable characteristics is that they be:

Markdown is great on the first two, but weak on the third; this is illustrated by the fact that different Markdown engines each have their own “dialect” of Markdown. In contrast, HTML is great on the third characteristic, but bad on the other two.

Gemtext manages to achieve all three, primarily by limiting its feature set. Since the format specifies UTF-8 encoding, it’s arguably even easier to parse than a plain text file.

From a Permacomputing standpoint, document formats that are easy for people to read and author are a boon. Gemtext rendering is basically trivial, but it’s also unnecessary, as long as you can read characters out of a file you can find out what you need to know — without unused markup data complicating the process.

Home