We do not need another competing standard here. Markdown is adequate and more importantly widely adopted and growing.
And I don't think org-mode's babel features really exist in Markdown? It's more like having python notebooks right in there (any language really).
I think the neatest part of org-babel is the source code block execution, & the various ways it supports for configuring output. This allows for org files to be "plaintext notebooks" (like jupyter in plaintext"). -- It's really surprising that this part is not more common.
More niche is the "babel" part of that: because the code blocks can take variables as inputs, and output values, this allows a polyglot notebook where values from e.g. Python get passed to R and plotted or so. -- Cute idea, although I've never found it too useful. The supported types are (unsurprisingly) limited, and the language support for code blocks is held together by duct tape.
(Even more niche is the noweb syntax for proper "literate programming". Which is mostly discussed about how awful it is to use in practice?)
Of course, org also has a long tail of neat features (like how each heading can have properties attached to it, as well as tags, and the task management that relates to this).
I think it is because of low Emacs adoption and other editors not having enough support.
The problem with polyglot notebook workflow is probably, that you can only use it well for small data, or at least not big data, because who wants to have a million lines of output suddenly appear in the buffer, only to then read them as input for the next language ... That would be a tremendous amount of computational overhead. And if we didn't have that, we would need a way to pass a proper value from one language to the other.
What I also like is, that you can define code blocks that are used as formulas for spreadsheets (tables) inside the document. That's quite powerful too.
> (Even more niche is the noweb syntax for proper "literate programming". Which is mostly discussed about how awful it is to use in practice?)
I don't find it very awful to use. I have used that for working through computer programming books and it was fabulous.
Just wanted to say that I share data between different blocks in different languages through files and env variables (I add :session shared to the src blocks that need to access this). That is useful also to have src blocks you can execute repeatedly and that depend on something like an aws identity being assumed (you just assume it in the first block that shares the session).
I agree it's messy, it's just a mess that works for me.
With org mode in mind, ideally you would have language support for this ie. Comments are scoped metadata that can be formatted, tested, linked etc.
You need a well defined spec like djot as a DSL for this to work, so that parsers can be easily written for it. This level of language support allows many different views onto the source code. We’re not there yet.
There’s no reason you couldn’t do something similar with markdown code blocks if someone were so inclined. But that’s tool dependent, not syntax.
I sort of agree with Karl’s point about there being too many standards of markdown, but I doubt org mode would have survived the same level of popularity without suffering the same fate.
It doesn’t help that there is no standard for org mode. You can only really use and take advantage of its power in emacs. It isn’t susceptible to lossy transformations because there’s only one real org mode editor.
But not all is well with Org Mode syntax either. Many git hosters have only a very rudimentary implementation of a parser and writing a parser for it is not actually that easy. Its dynamic nature requires at least a 2 step approach of parsing and then later checking all kinds of definitions at the top of a file and further processing the document according to that. It's power comes at that cost. That's probably why we have so many Markdowns, but only one Org Mode (OK maybe a few, counting Vim and VSCodium plugins, that achieve a feature subset).
I will say though, that org mode syntax is much better suited for writing technical documentation than markdown. The only issue is, that not so many people know it or want to learn it, and I don't know a way to change that. Perhaps that effort to have the org mode syntax separately defined (https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Over...) by the same author will help creating more support for the format in various tools.
Is it though? Like for example, I often deal with Org-mode documents of several thousand lines of text and I honestly don't know any piece of software that can acceptably handle multi-thousand lines of markdown.
Emacs/Org-mode has tons of different ways to navigate and search through these large bodies - the outline nature of the structure is perfect for that - there's narrowing, collapsing/expanding, sparse-tree search, flexible sorting, indirect buffers, imenu, overlays and text properties that can render the text conditionally, etc.
I read HN and Reddit threads in Org-mode format¹; I browse my Jira board and tickets in Org-mode², I have Wiktionary lookup³ and Thesaurus⁴ - all in Org-mode.
¹ https://youtu.be/ud3Gmxg5UZg
² https://github.com/agzam/go-jira.el
³ https://github.com/agzam/wiktionary-bro.el
⁴ https://github.com/agzam/mw-thesaurus.el
Comparing Org-mode and Markdown and saying "Markdown is widely used [and thus it's better]" is wildly immature - popularity doesn't determine fitness for purpose - PHP is more widely used than Rust or Zig, but that doesn't make it "better" for systems programming.
I can agree, Markdown is adequate for relatively small documents like README files, but it's nowhere close to even try to compete with Org-mode in so many different aspects far beyond just the markdown format structure.
But be that as it may, if Markdown is inadequate for a variety of tasks, why do people use it for a variety of tasks? Your rebuttal is just “Here’s a task or two that I do that I think Org format is better for.” Fine. I don’t have an opinion about your tasks. I believe you that Org is better for those for you. But neither do those cases rebut the fact that MANY MORE people use Markdown quite successfully on a daily basis than Org for a wide variety of tasks (blogging, documentation, personal information management, etc.). Can Org also do those things? Yes, surely. Can Org do more than those things? Surely. But so can Markdown. So, if you want to say “Org format is better for ME and I can do more with it because it’s more feature full,” then I’d reply, “I’m sure you’re right.” But if you’re saying “Org is better for everyone,” well, then, the data just doesn’t support that.
And for the record I did not say that “Markdown is better.” You are putting words in my mouth. I said it was adequate for a wide variety of tasks. It works. It is sufficient. My proof for that is that it’s widely used for a variety of tasks. That’s it. Q.E.D.
It just cannot, because THAT'S THE POINT - it is by design. You guys with little or no exposure to Org-mode keep arguing that Markdown somehow can be replacement or be a "better" version of Org-mode. Well, IT CANNOT. Period!
That is because they have different design goals, different applications and different use-cases. I would love to use Markdown if it was clearly sufficient for the things I do - well, it is not! Do I then curse and abandon Markdown? No, of course - I would not. It still useful for certain tasks. Just because it's used for a variety of tasks, it doesn't mean it can replace Org-mode anytime soon. Just like MS Word format can't and never would replace LaTeX or PDF.
But if you mean just the file format as it's used by say like Github to render README files then yeah markdown is perfectly adequate and org mode doesn't really bring a whole lot to the party.
You posted an opinion. Now, I'm very curious how you came to your conclusion: was is adequate? How to you compare?
Did you read the article and got the reasons mentioned why MD can be problematic?
I think you're wildly confused about both of these thing. Your objection assumes standards are about serialization format (how to write things down). But org-mode isn't primarily competing on that. It's competing on semantics - what the structure means to the system.
Markdown solves a problem of presentation - how to write text that converts to HTML or PDF. It's intentionally minimal because its job is: "make readable text that also renders nicely". Org-mode solves a problem of computation and workflow. It's a syntax for meaning - how to encode structure that a program can act on.
Markdown doesn't have task states, Markdown doesn't execute code, Markdown doesn't have metadata.
You could theoretically write org content in markdown syntax, but then you'd lose:
- Task state tracking
- Code execution
- Agenda queries
- Time-based organization
- Dynamic folding based on TODO status, and many more things
These aren't "nice-to-haves" - they're the point. Org-mode exists because markdown deliberately chose not to have these. They're orthogonal solutions.
When you say "we don't need another competing standard", the real issue is intermediate layers - CommonMark, MultiMarkdown, Pandoc's extended markdown, GitHub Flavored Markdown - these perhaps are redundant and fragmenting. But org-mode isn't trying to be a markdown variant. It's trying to be an execution environment that happens to be text-based.