Obsidian Flavored Markdown extensions

[kepano]

Describe your proposed improvement and the problem it solves.

Add a reader and writer for Obsidian Flavored Markdown. Obsidian Flavored Markdown combines features from CommonMark, GitHub Flavored Markdown and LaTeX, as well as several extensions inspired by wiki markup.

Syntax	Description
[[Link]]	Internal links
![[Link]]	Embed files
![[Link#^id]]	Block references
^id	Defining a block
%%Text%%	Comments
~~Text~~	Strikethroughs
==Text==	Highlights
```	Code blocks
- [ ]	Incomplete task
- [x]	Completed task
> [!note]	Callouts
(GFM syntax)	Tables

Describe alternatives you've considered.

Most of these extensions exist in one form or another within Pandoc, but it seems like it would be convenient to bundle them all together in a way that makes converting to/from Obsidian files easier. I'd like to explore implementing this myself, but wanted to first gauge interest.

[jgm]

I think we already have all the needed extensions, except for [^id] for defining a block (and similarly "block references") and comments. EDIT: and embed files.
So, if these things were implemented, one could easily package obsidian flavored markdown as a set of extensions on top of commonmark.

[jgm]

Note that to make these extensions on top of commonmark, one would have to add modules to commonmark-extensions. This parsing work would not be done in pandoc itself, though support for the new features in the writer would have to be done in pandoc's markdown writer.

[pidgeon777]

Hello, I would like to kindly inquire about any updates regarding the support for Obsidian's syntax.

[xieve]

I tried to use the existing extensions, but they cover even less than I had assumed they would:

markdown_strict+mark+wikilinks_title_after_pipe+space_in_atx_header+startnum+autolink_bare_uris+footnotes+pipe_tables+strikeout+task_lists+tex_math_dollars+yaml_metadata_block+inline_notes+backtick_code_blocks+fenced_code_attributes+all_symbols_escapable+intraword_underscores+markdown_in_html_blocks+auto_identifiers+lists_without_preceding_blankline+hard_line_breaks

is most notably missing alerts (not supported by markdown_strict), and

gfm+wikilinks_title_after_pipe-tex_math_gfm

is missing mark (not supported by gfm). Nonetheless, maybe this helps someone. I'd say the gfm one is a better fit for md → other formats, while the markdown_strict one is a better fit for other formats → md.

[jgm]

alerts is supported by markdown_strict in the most recent versions of pandoc.

[nathanlesage]

I just saw this issue and was a bit worried about the proposal. I strongly advise against implementing any of this syntax directly into Pandoc unless it is (a) widely used and (b) not context-dependent. Pandoc is a universal document converter, but if it starts to implement opinionated and context-dependent syntax, then it becomes a rather particular document converter.

Instead, I suggest implementing such syntax using custom Lua filters. This way, the custom and context-dependent parts are kept out of the Pandoc core and cannot confuse users who may wonder why an extension produces only broken links or other elements. I'd argue that, in this regard, even the recent addition of wiki link syntax was doubtful. Pandoc has no way of knowing which file to link to, so unless one exports a file into the same directory and the linked file happens to also reside there, the resulting link will not lead anywhere.

That's the reason Zettlr implements any custom syntax that is either context-dependent or not widely used as Lua-filters. It enables us to parse and produce correct export results without cluttering Pandoc with extensions that simply doesn't make sense outside the Zettlr environment. Also, for most syntactical elements, there is either already support, or support for an alternative and more widely used syntax. For example the comment proposal, which can be achieved using the much more common <!-- comment --> syntax, keeping files compatible across the ecosystem without locking users into a specific app.

Take a look at Zettlr's custom filters for an example: https://github.com/Zettlr/Zettlr/tree/develop/static/lua-filter

[kepano]

@nathanlesage At this point I think it's fair to say that this syntax is widely used. At the time I had opened this issue there were maybe 3-4 apps supporting it, but now it's closer to 20 (that I know of). Pandoc already supports many wiki markup formats so it seems in keeping with the philosophy of the project, but I will let jgm decide that. PR #11135 implements it.

[nathanlesage]

@nathanlesage At this point I think it's fair to say that this syntax is widely used. At the time I had opened this issue there were maybe 3-4 apps supporting it, but now it's closer to 20 (that I know of). Pandoc already supports many wiki markup formats so it seems in keeping with the philosophy of the project, but I will let jgm decide that. PR #11135 implements it.

Really? I haven't noticed that, but I also haven't been using many apps except Zettlr, Obsidian, and Joplin in the past years. Can you name some...? If so it might be time to consider this for Zettlr as well, would make it easier to ensure cross compatibility.