Feature request: export to markdown/GFM/Pandoc-flavored markdown/common markdown flavors

[Pandapip1]

Quarkdown seems great, it seemingly solves all the issues I have with pandoc. However, because it's so different from normal markdown, while my pandoc-based READMEs can typically be rendered by GitHub, quarkdown's... can't. I'd like two things:

1. A separate file extension for quarkdown files, as they aren't really markdown anymore (this should be trivial to implement which is why I'm putting it in the same GitHub issue)
2. The ability to render to a normal markdown file

Thank you!

[alerque]

1. A separate file extension for quarkdown files

The expected extension for Quarkdown files is already .qd, not .md (it was .qmd for a while but changed in the last breaking release).

[iamgio]

@Pandapip1 exporting to Markdown has been on the to-do list for some time. The problem is Markdown is a subset of Quarkdown, hence there is no way to represent some layout elements in pure Markdown (e.g. stacks, collapsibles, text size, ...) and those would end up being rendered to HTML as a fallback.

GitHub, like other platforms, sanitizes HTML content and removes properties such as CSS style. That means complex Quarkdown layouts will definitely break, and I'm not sure that's a good starting point to support a new rendering target.

[alerque]

I'm not sure that's a good starting point to support a new rendering target.

I don't think it is remotely feasible to support Markdown as a rendering target, only a content export target. As such just stripping out all layout and styling bits with no semantic meaning would be expected. Target something akin to Pandoc's internal AST node types only.

[Pandapip1]

Yeah, that was what I was aiming for. I've got a README.qd (primarily bc of the bibliography) but GitHub obviously doesn't render .qd files. I'm not planning on applying any styling whatsoever. I am very specifically using it to describe the document.

[iamgio]

I guess GFM export could work out then.

Question, also for @alerque: do you believe I should still render Markdown-unsupported elements to HTML? I personally believe so - the hosting platforms (e.g. GitHub) will then strip them off if it's their policy.

[alerque]

My personal use cases would lead to a "no" answer to that. Rendering them to HTML when exporting to Markdown assumes that the Markdown reader in the next step of the workflow is going to have any understanding of HTML. That is true for some readers, but not many others. I would prefer to have the elements "downgraded" to something –anything– where the content is valid Markdown even if the semantics of what it was for are lost.

That being said there are going to be people with different workflows and use cases that might want exactly the opposite. So maybe it should be an option?

[Pandapip1]

valid Markdown

What counts as "valid Markdown" is not well-defined. There isn't an official Markdown spec, rather many competing ones (GFM, CommonMark, Pandoc, etc...). For example, CommonMark doesn't support $L^AT_EX$, but I'd argue the correct move is neither of the two proposed options (convert it into plaintext or render to HTML), rather, it should be kept as-is. But obviously other people might have other opinions, and both Pandoc and GFM have no problems with LaTeX equations.

I think the best thing to do for now is have a basic exporter that simply evaluates all the functions and variables and assumes the result is going to be valid Markdown according to whatever viewer/renderer/whatever the user puts it through next.