undefined

points

[-]

Rendering Org in markdown is a solved problem, but wanting Markdown as the source is nuanced. It's difficult to achieve because there's no single agreement or convention - Org is not just markup syntax, its headings have records with types slots: TODO keyword, priority, tags, properties drawer, clock entries, etc. - Markdown has none of this. A CommonMark heading is a line of text; the spec does not even define a subtree, so folding, refiling and archiving need tree semantics layered on top.

So, you need to invent slots. Logseq did exactly that - all the org-mode specific lines get lifted verbatim into .md. Obsidian did it differently with emoji fields or Dataview inline fields (or whatever they called). Neither produces portable Markdown. GitHub renders those files as literal noise. The portability benefit that motivated the move evaporates the moment you add the metadata you need.

And then you'd have to build a specialized parser - there's no equivalent of `org-element` for Markdown. Sure, tree-sitter helps to some extent, but you're still lacking a semantic layer that turns nodes into records.

In essence - for Emacs to treat Markdown as Org-mode, we need to change Markdown, once that happens (if ever) Emacs can follow. But at this point it is already such a mess, it's crazy. Take front-matter alone - it's not CommonMark, it is a Jekyll convention that each tool does differently, and it is per-file, so your unit of thought is limited to become a file. That is the Obsidian/Denote/zk design, it works - but it moves your outline into the filesystem. You lose refile, subtree archive, narrowing, cut-and-yank of a subtree, and "this TODO belongs under that project heading". Org gives you both: file keywords at the top, property drawers on every heading, with inheritance down the subtree that front-matter structurally cannot express.

by Jtsummers11 hours ago|

prev|

[-]

Markdown didn't even exist when org-mode was first developed and released with many of the features you describe. But also, once you start extending markdown to support all these things you start getting something that's not markdown, it's markdown-based but something distinct since you'd rapidly lose compatibility with other markdown tools if you start incorporating custom annotations into it.

by kodoman11 hours ago|

parent|

[-]

I really don't dislike org-mode and respect it and you are right that org-mode was first.

The point is that markdown could have todo's or virtually any other aspect that org mode supports put into it without changing the markdown standard and layer org functionality and various features on top for example todo's could simply be italic's starting with todo: so `# todo:todo hello` could be parsed as a todo entry marked as todo.

by iLemming10 hours ago|

parent|

[-]

It's not that simple. The formats differ structurally. Org-mode is a proper tree - that's its fundamental basis. A tree where each branch can hold k/v pairs of metadata. Markdown is rather a flat sequence of blocks with level markers sprinkled in. Neither of that (proper tree or records) fundamentally supported in Markdown within an agreed spec - pandoc attach attributes on its own way, kramdown does it differently, etc. That's the most difficult part - there's no agreement of what Markdown is - each tool treats it differently. While Org doesn't have a formal spec either, there's no mess, because "the spec" is in the Elisp code it ships with. Even if there's fragmentation (Org-Roam, Denote, howm, vulpea), it is all contained within emacs-land.

If you want to use markdown for Agenda and calendaring in Emacs you'd have to invent a different subset of markdown, most likely poorly supported anywhere else. And if you get there, then it begets a question - why? If we already have something far better and it's called Org-mode?