Quarkdown: Markdown with Superpowers | Hacker News Reader

Quarkdown: Markdown with Superpowers

iamgio.eu

36 pointsxiaodai60 comments

Quarkdown could be amazing, but they’re not doing a good job of selling it with such an awful, unusable website.

I'm like you, got in two slides, then went back to hn

Not sure how it works on desktop, but on mobile I literally closed the website after scrolling down two times.

I closed it on my desktop after a few minutes when I couldn't figure out how to navigate. Others are talking about slides, but I didn't see any.

My background is human machine interaction. I have a reflexive urge to not look for "undiscoverable" navigation elements and close a page when I see them. The world needs better UI, and I'm doing my part by not giving my eyeballs to bad UI.

It looks like a Reveal.js presentation. I wouldn't say I saw “slides”, but rather a single slide, which is a poor indication that it's a slideshow (which needs to be navigated with the arrow keys or with the arrow buttons in the bottom right). A website that doesn't show more information on scrolling down is incredibly poorly designed.

There are "slideshow" forward and backward buttons at bottom left. Horrible UX, and when I opened it, actually thought it was vapourware because the landing page was so devoid of information.

The Latex to Quarkdown comparison in the github README[0] is a much better introduction than the slide show.

Or, maybe I'm just an old and ornery programmer who frequently says in his head "GET TO THE POINT!"

[0]: https://github.com/iamgio/quarkdown?tab=readme-ov-file#compa...

Indeed, but listing LaTeX as "No scripting" seems odd at best

Very interesting. If people keeps creating their own extensions of Markdown it's because there's a need somewhere for a comprehensive markup language. Markdown wasn't invented with documentation in mind, for example, so now we have rST, Asciidoc, Markdoc, Djot, etc. I really wish a powerful standard emerged, though.

> If people keeps creating their own extensions of Markdown it's because there's a need

This is a general misconception about why people create. People don't always create to fill a need - in most cases, motivation to create is intrinsic rather than extrinsic.

As for having a comprehensive markup language - every product & creative avenue in every field in the world needs to contend with balancing complexity & expressiveness with accessibility & simplicity. Markdown errs heavily on the latter side for the writer but comes with natural trade-offs (e.g. it leans heavily on the complexity side for parser-developers) - that push-and-pull will always motivate folk to try & strive for the magical best of both worlds.

People often create to fulfill a need. The need might be intrinsic -- the need to create something.

But back to the point: Agreed, you described well the existing tension. At one end of the spectrum you've systems like LaTeX and DITA; on the opposite side, Markdown. I don't think Markdown should ever be extended. If anything, it should be encapsulated.

Perhaps it could be some kind of hyper text markup language

doesn't sound good enough, let's add some kind of cascading style sheet to it, some java script, wrap it up in something called electron slap the word app on it and ship it.

You forgot Typst

https://news.ycombinator.com/item?id=41014941

And before that we had roff.

We should move on to Djot , it is future of markdown by developer of commonmark and pandoc.

The pedigree is outstanding, but what makes Djot superior to, say, reStructuredText or Asciidoc?

There's page about the design decisions: https://github.com/jgm/djot#rationale

TLDR: single pass, multiple (identical) implementations on different platforms, HTML is not an implicit target, uniform syntax (including attribute syntax)

this looks like really good improvements over commonmark. i'd like to start using djot to render existing markdown files, and slowly start writing new files in djot utilizing some of the extra features. i tend to write my markdown such that it would mostly be a valid djot file anyway (no html, #-only for headings, empty lines between all block elements, etc.) -- but i see one design choice that prevents me from making this transition.

it looks like djot has changed the syntax for inline italic/bold text in a way that's incompatible with markdown. i see why it was done, but it's a shame because it looks like this is the only thing that really prevents rolling this out as a "soft" transition.

> I really wish a powerful standard emerged, though

Relevant xkcd: https://xkcd.com/927/

> I really wish a powerful standard emerged, though.

This is not possible. Any standard powerful enough for everything is also too complex for simple things! Most documents are simple and don't need the power. There is a good argument that authors shouldn't even have access to layout (ever see a 4th grader write a report - they spend hours preparing the table of context, index and other such layout details leaving little time for the content!), you may not agree with the argument in the end but you should understand it.

There will always be debate about what is the right things to include in your documentation standards. Since there are multiple different types of documents with different requirements there will be different answers.

Maybe some segmentation into minimal, average, and deluxe would help the Goldilocks situation.

Unfortunately it is easy to create something that is "better" for which ever situation you are in. It is much harder to think "I can but I shouldn't so I won't". (or maybe I'll do it for fun in my basement and then burn the code once I learned what there is to learn).

The above doesn't apply to markup. There are lots of other situations where you can do something better, but it won't be enough better to be worth doing. (and of course there are also cases where it really is better by enough)

With SGML, there is a powerful standard and prior art. SGML SHORTREF declarations let you define most of markdown's span- and block-level syntax by mapping tokens to start-/end-tags or any other replacement string in a state-dependent fashion such that eg toggling bold text on and off is easy, with special recognition of newline/end-of-line "tokens", etc. The mapping to HTML is very natural, also because using in-line (or block-level) HTML angle-bracket markup tags works exactly as in markdown. Though unlike markdown, SGML will complain about syntax errors, rather than format incomplete markdown syntax as verbatim text, and markdown "referential links" put anywhere before or after the place where it is referenced won't work.

Text macros (entities) come for free with this approach, and SGML SHORTREF customizations also can be used for any number of additional document-specific conventions on top of markdown.

Even if not actually using SGML but one of the hundreds of markdown-to-HTML converters, checking for SGML upward compatibility is a useful thing to do IMO because of the already crowded space of tokens recognized in marked up text and their recognition priorities.

I've heard this before. It sounds good, but where to start?

For markdown-in-SGML specifically, there's a tutorial at https://sgmljs.net/docs/producing-html-tutorial/producing-ht... also covering usage of entities/text macros.

Unfortunately the result prevents me from zooming in on mobile, so I can't see the code examples.

Each complication over Markdown is utterly interesting to me. Tho I never stick at one due to diffusion

Navigate with the Right-Arrow key or by clicking the arrow in the bottom right corner.

I like it. It's not complex but you can do complex stuff. It is why I use AsciiDoc. I don't think creating a new (and better) markdown will win hearts... yes it is nice but you need to compete with a lot of attempts to improve it. ... relevant XKCD: https://xkcd.com/927/

At the end of each slide animation, the slide seems to jump a few pixels.

I'm on Firefox.

but, i have org-mode already!

this looks very nice though it also is close to typst. a comparison would be interesting.

I misread "quark" as "quirk" and thought to myself "please don't bring back IE 'quirk mode'"

No! Markdown is made to be simple. Don’t use it for complex projects. Use properly thought out markup languages for that, like Asciidoc.

Thanks for the reminder about Asciidoc! A few years ago I dug into various markup languages looking for a better way to draft legal documents. Asciidoc was the best balance of power & simplicity.

Unfortunately the ecosystem was pretty weak. In subsequent years there has been an effort to standardize the spec, which should unlock better tooling. I need to check in on that…

They’re still working on the spec. Last release was five months ago. So, slow progress continues. https://gitlab.eclipse.org/eclipse/asciidoc-lang/asciidoc-la...

Here are the minutes from the last working group meeting, back in Feb. looks like they’ll meet again in September

https://docs.google.com/document/u/0/d/1eqB2w5pungP2vxiF_DeM...

Have you checked out Typst?

I have tried ASCII doc and haven't really enjoyed it.

Typst on the other hand is simple, fast, powerful and ergonomic at the same time.

At a glance, Typst looks more like a competitor to Latex, not Markdown/Asciidoc/rST.

Typst is trying to take on LaTeX: high-quality PDF output, equation typesetting, citation and reference systems, programmability, etc.

But if you look closer, the actual syntax of Typst is clearly a mix of MarkDown and AsciiDoc (e.g. code blocks and lists work like MarkDown, while headers work like AsciiDoc, and I think the math syntax is to some degree inspired by AsciiMath from the AsciiDoc ecosystem).

As someone who mainly uses MarkDown to author PDFs, I find Typst to be a clear competitor to Markdown/AsciiDoc/Org as well as TeX. I think they're working on basic Typst support for Pandoc, in which case you might soon be able to generate HTML with it too.

What's your markdown to pdf tool(s) of choice?

The king in this space is Pandoc. It supports most things you might need in "serious" documents: figures, tables, equations, references, citations, etc. You can even customize the TeX export template if you need more control over the output. And if you need to later, you can easily re-export the same document to TeX, DOCX, or HTML.

Lately, I've also been using Quarto a bit. The default export is HTML but it also supports PDF. It's nice if you're into "literate programming", where you write code blocks (e.g. Python snippets) in a MarkDown file, and those code blocks are automatically used to generate figures, tables, etc. in your MarkDown file on export.

If you want something that "just works" and are not averse to commercial apps, I can recommend giving "iA Writer" a shot. It has a built-in preview and export solution that is lightning fast and has good support for equations. But I wouldn't use its export for anything important, as the output is clearly draft quality, and the MarkDown support lacks features like citations. (Though it supports footnotes, so for informal documents you can abuse that for citations.)

Yes, but it's probably worth another look as my use cases have shifted around. I'm 1000% not interested in signing up for their SaaS (corporate data security concerns) but I see that they have an open source CLI [0] so maybe I'll try that. Also, looks like they offer a self-hosted enterprise offering now, which is intriguing.

My use cases include:

- Drafting, reviewing and iterating over legal documents, especially contracts - Technical and business process documentation - Long-form, print-friendly report generation, including data visualization, tables and images

[0] https://github.com/typst/typst

The open-source CLI is indeed all you need. On Mac, I could just do `brew install typst` to get the compiler, and then run it on a local `*.typ` file. I'm sure there are packages available for most Linux distributions as well by now.

I wonder about the other direction - how much can you remove from Markdown until it's no longer useful enough for wide adoption?

How about:

    one heading level only
    no nesting (of lists or styles)
    tables can only contain plain text (not even links!)
    either indented or fenced code blocks, but not both

But keep the html escape hatch. If anyone needs one of the missing features, they can drop down to html. Just a bit more friction.

Remove img support. Its severely lacking anyways. Most images need more meta data such as sizes, but also modern images are responsive with different resolutions etc.

I recently made a markdown parser that is essentially this. It runs my blog. My table parser is non-standard, though, as I hate typing up markdown tables. Instead, I’m using a special code block “gen:table” and I just type up a whitespace-aligned table.

The raw markdown table ends up looking like a table even with standard markdown processors since it just renders as an unknown code block.

Tables can be very nice to work with in a text editor with some convenience features like automatic alignment and tab-to-next-cell. At least that's my experience using tables in emacs with org-mode files. But I imagine there's quite a lot going on behind the scenes to make that work, plus there's some inflexible syntax used to recognize when your cursor is in a table.

But I like your approach of leveraging monospace fonts to work as informal tables.

gemtext (the native presentation format for gemini capsules) is a markdown-like language which only uses the first three characters of each line to determine the presentation mode for that line. it's designed so that it's trivial to create a renderer, even on retro 8-bit computers (determine presentation mode, set up the font, then just dump the buffer until you hit a newline). it supports paragraphs, headings (3 levels), links (not inline with text, must be on its own line), lists (unordered), blockquotes, and preformatted text. there is zero inline formatting (not even a way to emphasize words in a paragraph).

https://gemini.flounder.online/docs/gemtext.gmi

Amazing, that hits the spot.

I wonder if we can replace Markdown by an LLM entirely. Just tell it what you want and how it should look in natural English, and then use that as your source file.

You would need LLM output to be deterministic first (i.e., given the same set of English instructions, you get the exact same output every time). And that’s not even getting into the inherent problems with the nuances of natural language. For something like this you really do need a tailor-made language suited to the task.

DL libraries like pytorch are completely deterministic.

Now you need high end nvidia GPU just to render text ...

I guess OP never get why there is markdown in first place. Why another scripting lang inside Markdown which suppose to be readble , natural to write , easy to render.

```

.function {greet}

    to from:

    \*Hello, .to\* from .from!

.greet {world} from:{Giorgio}

```

No Hell No , You don't need that in a markdown-like doc. If you want that just use HTML with js. or MDSvex .

Reply on news.ycombinator.com