undefined

points

[-]

> What is wrong with markdown mode?

Nothing. It's just not Org-mode, and thus many great features of Org just not possible - sparse tree search; timestamps with built-in calendaring features; outline features like narrow-to-subtree; editing the subtree in an indirect buffer; executable code blocks; embedded LaTeX snippets; real tables with spreadsheet-like capability; checkbox statistics cookies - [/] and [%]; org-sort; column views; tags and tag inheritance; etc.

Anyone who's familiar with even a small subset of things that's possible in Org-mode and unlikely ever be supported in Markdown (just because there's no agreed format standard) have no confusion about it - Org-mode is absolutely superior. But superior doesn't mean universally better for everyone. The biggest drag of Org-mode is that it can never fully exist outside of Emacs. Yet Markdown can't ever fully cover its grounds (even in Emacs), simply because Markdown has to exist and work outside of Emacs as well.

by kodoman12 hours ago|

parent|

[-]

Else where in this thread you can see my argument is that all org-mode features such as calendar dates, todo's, take your pick could be implemented separate to and utilize markdown (or any other format) for actually rending to. I am familiar with org mode but dislike how it sometimes pushes against simply using elisp for things like setting up todo nodes and possible todo values. couple that with the fact that one could in theory just render this all out to markdown instead and come up with some way to render todos into md.

by iLemming11 hours ago|

parent|

[-]

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 Jtsummers12 hours ago|

parent|

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 kodoman12 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 iLemming11 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?

by taude14 hours ago|

prev|

[-]

Yeup, I would love to have some of the org/agenda operations/views on a regular markdown file. Especially so I could just copy it raw out, and paste into other markdown-centric tools, github md files, etc. for colaborating with others.

Since markdown is becoming so prevalent. Even our product managers are becoming natively conversant with it, I'd just prefer to have as markdown first world.

(don't get me started ranting about how Atlassian and Slack have migrated away from markdown and to proprietary formats....).

by kodoman14 hours ago|

parent|

[-]

Yes must say I have found myself moving away from org and looking at it as an annoyance wrapping up many excellent features that could be wrapped up in simple elisp function and structures that could then just be encoded in what every way one likes, it seems to me that for example todo lists are actually better as nested lisp lists, And then you can simply render as what ever you like. Of course one might like to serialize back as well but I have often wondered about it.

I definitely think markdown has won (at org was never going to 'win' of course given it's limited scope) and actually is probably what we should just all be using and accept.

by taude13 hours ago|

parent|

[-]

That's actually not a bad mindset, especially when lisp can be vibed so easily. I could actually see myself building out my own library that does the things I want over markdown.

- have it look through all md files in a directory, collect all the todos into a main view

- look for items tagged with a date

- support customer tagging, and provide workflow exports for each one...

- behind the scenes git management for files

- etc...

I've been wanting to build a collaborative markdown editor for awhile now, making it so that different front-ends could work with it is an interesting thing to think about....

by kodoman13 hours ago|

parent|

[-]

My thinking was lean into lisp lists rather then the actual rendered format, so that instead of a text buffer (although you could always open up a text buffer that is the lisp list) you have a list that you can use normal elisp functions that is bindable to keys and highly customizable and your only really building fairly simple elisp machinery on top and you can just use an alist (though you could use a plist I think alist's work better for todos) to represent todo's and just use assoc and setf and friends to do your modifications.

Of course one might also want to actually build out todo nodes as CLOS style objects. Only caveat hear is that you would need to decide how the object should be serialized and deserialized and the deserializing has to be more precise.

serializing and deserializing to MD should be easy I think since all we need to do is read in headings and list items into lists with some denotation to the type it was.

Those are just my thoughts on the topic. My thinking has been I have gotten fed up with emacs modes that are good and a lot of effort to write but just end up adding a lot of stuff on top that make it difficult to customize or customize the the standard way and returning to simple lists could be good.

by skydhash12 hours ago|

parent|

[-]

You might just as well require a sqlite db as the persistence layer. Emacs has always been about using plain text files as both data and interface while lisp is the control mechanism.

That’s why you got org files and a handful of lisp functions to turn them into a living documents. Using lists take that aspect away while markdown is just not that good to serve such a role.