Comment by throw__away7391
1 day ago
We do not need another competing standard here. Markdown is adequate and more importantly widely adopted and growing.
1 day ago
We do not need another competing standard here. Markdown is adequate and more importantly widely adopted and growing.
You statement gives me the impression that you haven't read a single paragraph from the article you're commenting on.
org-mode's first release was in 2003, Markdown apparently in 2004. So not just "yet another standard"
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).
> And I don't think org-mode's babel features really exist in Markdown
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).
> It's really surprising that this part is not more common.
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.
I agree about the duct tape, which I also use often around the house, so maybe that's why I like org-babel :)
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.
1 reply →
Babel features are kind of a moot point if you’re just talking about the syntax, which seems to be the purpose of the post. Most of the reason to use org mode is tied to emacs.
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.
Well, but I am not aware of anyone having come up with a good syntax to do babel things in Markdown. Markdown and Org Mode also set out to serve different purposes. For a quick and dirty text Markdown might suffice, but the babel stuff and spreadsheet stuff enable a lot of use cases that Markdown simply doesn't cater to. We already have the implementation of all these nice things in Emacs. If we were to replicate them for some markdown dialect, they would probably be done half-right, before someone actually manages to get literate programming right for various languages, including what code to translate to, how to wrap or not wrap the code that is inside blocks, sessions, output formats, etc. We might as well use what we have with Emacs. There is probably a way to call Emacs' functionality from outside of Emacs, to treat it as a library.
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.
1 reply →
A) I'm aware and B) so what? Markdown is popular enough now that even people who aren't very technical and don't know that they're reading/writing Markdown are familiar with it. This is incredibly valuable and not something you can replicate through purely technical means, there are so many places where having a ubiquitous way to express in plain text is helpful. Markdown has grown into this role at the same time that the environment developed. You will not be able to recreate this situation.
> We do not need another competing standard here
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.
I don’t think anyone who gets really familiar with org can ever honestly say with a straight face that Markdown is adequate in comparison.
I did and I mentioned very particular reasons and arguments.
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?
“Adequate” is a very relative term. Adequate for what? The fact that Markdown is widely used quite successfully demonstrates that it is adequate for a wide variety of tasks. Yes, Org mode might cover more of the long tail, but Markdown clearly covers all the important cases to the point that it has achieved wide adoption.
> it is adequate for a wide variety of tasks
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.
1 reply →
If you mean org mode as it exists within the software emacs then yeah it's no contest. No markdown editor even comes close.
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.