11–20 of 221 posts
As it is, the * vs # for headings makes switching between the two uncomfortable.
And driving on the left is one of the most reasonable sides of the road to drive on, but in a country where everyone drives on the right, it’s good to accept that, though driving on the left offers just as many advantages, nonetheless you shouldn’t insist on continuing to do so.
Markdown is also one of the most reasonable markup languages to use for text, and it has won sufficient share that it should be your default choice for lightweight markup, no matter how reasonable org-mode is.
Earlier quoted context omitted.
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).
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 o…
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.
Earlier quoted context omitted.
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 va…
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.
Org format is reasonably intuitive (so is markdown). But org's real power comes from org-mode and the rest of Emacs. Being able to use it as PIM, as a quick way to write documents and export them, as a way to take notes, the keystrokes which are almost automatic for any Emacs user etc. This is really why it shines. I don't see much value for it as just a markdown format outside Emacs.
We do not need another competing standard here. Markdown is adequate and more importantly widely adopted and growing.
Does Org have a mechanism for escaping its own syntax? Last time I searched, to type *this* (keeping the asterisks) you had to insert a zero-width space (U+200B). In markdown you just escape them with \*this\*.
Looks like even the documentation for org-mode recommends using zero-width spaces: https://orgmode.org/manual/Escape-Character.html
I think org-mode was never primarily about its rendered output. Most users probably, like me, spend a lot of time (hours every day) in various org-mode documents, staring at what is essentially the raw mark-up. Org-mode in Emacs makes only a few minor changes to how the text is displayed, like hiding link targets, so you rarely look at the output. I export less than 1% of my org documents, so usually I don't care at all about what formatting renders like, as long as I get the mark-up correct enough that org-mode itself is functional (links can be followed, sections collapsed etc). The few documents I do want to export I can imagine using workarounds like the zero-width spaces, but it is not like there is often a need to have things looking like org-mode mark-up in the output.
For me at least, worrying about escaping mark-up would be too distracting and just add noise, as the raw mark-up is what I will read anyway. But I think some good way to escape things would not be a bad thing to have.
BTW there are verbatim blocks that can be used when you have entire lines of non-org content. And of course src-blocks. But that obviously does not handle every case escapes could be useful.
I've recently begun replacing Markdown with Gemini's .gmi/gemtext format. It is Markdown with fewer features. I appreciate the simplicity and it's tremendously easy for custom tools to parse. It has no inline formatting, only 3 levels of ATX headers (without trailing #s), one level of bullet points using only asterisk and not dash to delimit, does not merge touching non-whitespace lines (thus expecting one line per p…
Only complaint is that it handles line-breaks the way some Markdown variants do, with each line being one paragraph of text. I much prefer line-breaks to be just treated as whitespace and using double breaks to end paragraphs, like e.g. Pandoc's Markdown format (one reason I always use that when I render Markdown).