I've been on this bandwagon for a long time! I proposed org as an interchange format for Productivity and PKM tools several years ago [0]. Org allows me to unify my bookmark manager with the rest of my PKM as well as to-do management in a way that I don't think is possible with markdown.
That said I think that AI is changing things as it becomes best practice to document and define everything in plain text for LLM consumption. Since the default text format is markdown (due to github and PKM tool support) more and more people are exposed to it as the one true markup language. So maybe the boat has sailed and org becomes another example of the better format that doesn't win out. OTOH LLMs slurp up org content just as easily as they do markdown, maybe more so given the richer syntax. So maybe there's still room for both?
Either way I think the losers are going to be Sharepoint, Confluence, Jira etc, maybe even wikis, ie all the non standard ways people have been documenting their work to date.
Like us org folks have been saying all along, just stick with plain text!
> "Either way I think the losers are going to be [...] maybe even wikis, ie all the non standard ways people have been documenting their work to date."
Org mode never touched ConnectedText for me; I'd probably still use it if the tool either had gotten open-sourced and/or taken over by a dedicated team (of professionals). Its pros were user friendlieness, powerful scripting, reliability, having an extremely good search functionality, and a small but dedicated community. In other words some things Org mode still has not. And getting text in and out was trivial.
Sadly, AFAIK, the dev threw in the towel after facing a refactorization of the code. Having single-dev complex applications is very seldom a sign of sustainability (SPOF).
And functioning wikis obviously implement standards; several of them can run on flat-file structures (e. g. TiddlyWiki). Org mode can or could run them as front-end. Et cetera.
I discovered and started using org-mode (and, as a result, Emacs) when I migrated from Evernote in '16. Today I use it for all my project, task and knowledge management needs, with some files going over 15MB in size. And I'm still loving it. Started out with headers only, and every time I wanted something more, it was always just there for the taking. Easy to use, and also crazy powerful. Can't think of anything else that exhibits both those traits at once.
How do you handle PDFs, images, HTML/rich text snippets? Asking because Evernote supported all of those. It’s what keeps me using that app, even though I cringe every time I open it.
- I can also do LaTeX PDF and raw tex, for undergrad student "professor points" :D (See examples in the github repo --- the "n Ways to FizzBuzz in Clojure" presentation. Which also was a live coding demo: https://www.youtube.com/watch?v=BTouODWov-A ... "demo live, or die trying", I say :D)
And... I mentioned my site... This is the build step, no Emacs needed :)
__shite_templating_compile_source_to_html() {
# If content has front matter metadata, it is presumed to be in a format
# that the content compiler can safely process and elide or ignore.
local file_type=${1:?"Fail. We expect file type of content like html, org, md etc."}
case ${file_type} in
html )
cat -
;;
md )
pandoc -f markdown -t html
;;
org )
pandoc -f org -t html
;;
esac
}
I've never used anything but plain text in org TBH. I know there are tools out there that make it possible/easy to work with certain binary files, but I've just never had such a use case. At most I'll put a link to a given file that opens it in a native viewer.
with webpages I just store the link, but maybe you want to download them? I've used singlefile extension to download and store copies and link from org.
with pdf I just store
evince /path.pdf &
and triple click to select and middle click in a terminal.
I've started using org-mode couple of years ago, and write documents using the basic features like headers and formatting, links between docs, and code sections, but still haven't figured out which power features are the ones worth investing time into, and would be the most useful. Which further features would you recommend digging into, based on your experience?
I suspect this is an issue for most org-mode users, we all use different things.
I have two real uses for org-mode; I write a "work log", or "diary", every day I'm at work which keeps track of meetings, tickets/issues I work on, pull-requests I review, etc.
Unrelated to that I have a property I rent out, and I keep a table for each year showing rent-received from my tenant. I have a little "database" of previous tenants, and their details.
When I add a new table row for this year, say "January 2026 | Sharon | €1000", that updates the global profit/loss table for the document as well as profit/loss for the current year AND a t able which just lists the tenants I've known, how much they paid, and how many months they rented for.
Both of these two use-cases use very different things. The diary is just a text-block as template, the financial stuff uses multiple tables, custom elisp code, and some summing operations.
I consider myself little above basics even after all this time. The features I use depend on what I'm doing at the time, and so I take a JIT approach to learning org-mode. I'd say just keep the main resources close by as they're very detailed, and search them whenever you're thinking of doing X thing.
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.
The value of Org outside Emacs would be the same value that Markdown has, if it had wider adoption. Voit's post makes a strong argument for Org syntax's ability to serve for all the things Markdown currently does, while being more consistent and concise than Markdown, and so he pushes for it to be more widely adopted. We know that in tech, the better format doesn't always win at first, or ever, but we can advocate!
org-mode is just much more complicated to implement though and just contains so much. it's also a todo app. It also lets you run code like a python notebook. it can show you your tasks in a calendar.
I've used "org-mode" todo apps on android, but people complain they can't really use it because it doesn't implement everything.
The advantage of the core markdown syntax is that you know it works everywhere and it works everywhere because it's small and easy to implement.
Fair enough. We can argue about the betterness of org but even if so, its enough better enough to push our something as popular as Markdown. The real item of value is org mode.
I've tried other things like Sphinx and it's tough to find something that checks all the boxes I need.
In general, though, I'm pretty impressed with Typst. I wrote a test program that takes the XML output from cmark-gfm and converts it to Typst with xsltproc. It produces PDFs in orders of magnitude less time than Pandoc/LaTeX. I use that now for all my casual PDF documents. https://github.com/beejjorgensen/xml2typ
Looks like it's getting there, but still needs some work. It's not obeying the book output or number sections. I can probably get the indexing going, though.
I've been using Org Mode for organizing my life in plain text for the past 10 years now.
Beorg on iOS [0] makes it great. I've also started using things like org-ql [1] and org-super-agenda [2] to make me even more productive.
I also have a daily log org file I use at work. It helps me keep track of what I need to do and what I've done. It makes yearly reviews easier as well!
Hi @cyrialize , Hopefully this is an acceptable level of self-promotion. It sounds like my browser extension, BrainTool might be useful in your workflow. It's kindof a bookmark/tab management tool. It syncs to a .org file and allows you to do things like mark tabs as a TODO, which you can then track in org-agenda etc. There's some brief descriptions and videos here:
https://braintool.org/2025/09/16/Browser-Workflows-with-Brai...
Oh wow this looks really awesome! I'll have to check it out.
I unfortunately primarily use Firefox, but still this is great. I've manually tried to keep track of bookmarks via org, but of course I'll always forget to update it.
I’ve looked into a log/journal date tree approach with my various activities across the day (meeting notes, independent work notes, etc) under the date. But then I prefer being able to look through headings that anchor on context first, then dates second (/eventually).
Does your daily log link to other parts of one org file, or other org files?
I’ve asked LLMs their opinions. But curious for yours!
Also thinking about trying denote. The filenames begin with dates, then use tags/keywords to keep the thread on recurring topics.
In each day heading I'll have either a short note (like saying what meeting happened), or a link to a separate org file.
I keep an org file for each JIRA ticket I'm working on, so I'll link it out there. The presence of a link indicates that I've worked on that ticket that day.
Then in each individual ticket file I'll just keep top level day headings with notes of what I've done on the ticket, as well as other headings.
For example, an org file for a ticket would look something like:
* PR 1
#+BEGIN_SRC markdown
I like to pre-write up my PRs in a doc block in markdown in org mode just to use my keybindings. I copy-paste when I create a PR.
#+END
* Monday 01/01/26
- Started work on this today, figuring out where in the codebase to touch
- Straightforward, got a PR out
When I need to find something, I use something like consult-org-heading or consult-outline or consult-line.
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.
If you think you'll ever want to use third-party tools to process that markup, or if some of your private files will transform into public files at some point, then yes, considering popularity makes a lot of sense.
If they're just text files you edit raw that will never interact with anything else but your text editor, then of course popularity doesn't matter at all. But in my experience, my use cases tend to expand over time.
The article even talks about org mode's interoperability, mainly about the fact that pandoc supports it. And then bizarrely ignores the fact that it has much less ecosystem support than Markdown. So this is very much a subject the article itself brings up, and something that therefore also deserves to be critiqued.
No? I’m pushing back against advocacy for broader adoption of org mode beyond personal file markup though, which is what I feel like this piece is arguing.
> note that this is not about Emacs at all. This is about Org mode syntax and its advantages even when used outside of Emacs.
One of the advantages of "going with the flow" when you can is that you benefit from numbers. You're a market of one, but by "going with the flow" the total market is huge.
Even if for me personally 185V mains power would be better, I can't buy gear for 185V, none of the electricians around here know how to work with it, the cables and sockets and everything else are defined around the prevailing systems at 220-250V here.
Maybe in my kitchen a 520mm dishwasher would be great, but alas dishwashers you can buy here are 600mm or 450mm ("slimeline") models, so 520mm isn't available.
With my poor hearing 14-bit PCM would be absolutely fine, but Sony's "Compact Disc" used 16-bit so that's what everybody uses and records by default.
If you work with Markdown, there are a lot of existing tools which are ready to use. There are tools for Org Mode, but maybe not as many.
There's definitely a sliding scale here. Refusing to use Twitter because it's full of Nazis is very different from refusing to conform to society's expectation that you wear clothes outside for example. There are people willing to spend most of their lives in jail because they refuse to wear clothes but almost all of us don't think that's a principle we care about enough to prioritise (also some of us get cold).
In my experience, not really. I'd love to use Typst, you have no idea -- but when most journals require you to use their LaTeX template, then my personal taste doesn't really enter into the equation.
Markdown (subjectively) looks better than Org when it’s plaintext - postfix headers and dashed lists are annoying to parse but they distinguish sections visually. Org by comparison feels like a sea of asterisks.
I don’t like using “-“ for bullets and “*” for headings. I do love underlines for underlined text, slash for italics, and asterisks for bold. Other than that, po-tay-to, po-tah-to. Let’s all just pick one and use it consistently. I do agree with the argument that says “Markdown” is meaningless and you’re always forced to ask “What do you mean by that? Which flavor, exactly?” But that happens with anything “lightweight” as it is inevitably extended to deal with more complex demands and becomes more heavyweight in the process.
Markdown is worse than other formats in many ways. It has several ambiguities, there are significant variations between implementations, fairly basic features like tables, footnotes, strikethrough, etc. are "extensions" that aren't widely supported.
The only real advantage of markdown is that it is has because more ubiquitous/popular than others, possibly in part because it is relatively easy to implement, as long as you don't care that much about exact compatibility with other implementations.
This is advice that I would have rolled with pre-Generative AI.
Today, I'm not so sure. I'm actually way used to zim-wiki syntax because that's what I started off with; and already "moving it around" is becoming orders of magnitude easier given the ability to vibe-code tons of little scripts that make it work better with everything else -- and while this might seem a bit counter to the point -- I think one can reasonably rely on the idea of "market share isn't that important anymore compared to 'you, personally, should use the thing that works the best for you because translation will get orders of magnitude easier.'"
I'm surprised nobody else brought it up - what are the pros of left-hand driving? Is it about where the controls are in relation to handedness? Some sort of safety benefit? Better visibility in certain scenarios? And are postal carriers in America who drive LLVs getting the _best_ or the _worst_ of both worlds?
I've driven both. Drove LHD for more than a decade in India. Now driving in RHD country for 2y now. Personally, I enjoy RHD more because I am right-handed and I get to do things easily with my RH. Otherwise, I realized that safety benefits comes from the driving discipline and not driving on a particular side of the road. Driving on Aus/Japan is way safer than India, despite all of them being LHD.
Markdown can be trivially embedded in org-mode, so no need to even miss out on that which "won sufficient share":
* Org with md block
#+begin_src markdown
.....
#+end_src
Markdown may be a winner, but preferring it when org-mode exists is like tying both arms behind my back and trying to do serious things with my feet.
Expressing complex HTML or LaTeX constructs in org-mode is more complicated than writing the raw HTML or LaTeX. So for complex things, I'll always fall back to writing HTML or LaTeX directly. Markdown, instead, just falls back to HTML. Whatever I can't express in markdown, I can simply insert the HTML by hand. These markup languages are always fine for simple things, but have a hard time expressing more complicated things.
Perhaps some kind of escape mechanism, like typst, would solve this. But org-mode doesn't.
That said, org-mode-the-program (not org-mode-the-syntax) is just fantastic, and nothing else comes close. For me, this doesn't outweigh its problems. Obsidian is a good-enough alternative.
I've recently converted my blog from org-mode to markdown. 1000 lines of elisp, replaced with 200 lines of Python, and a 50x speedup. Last year, I did the same for my journal. I'm a bit sad to "leave", but it does simplify things.
Which is neat, because when I `C-'` (M-x org-edit-special), it opens a temporary buffer with just the HTML, with the relevant syntax-aware editing mode turned on. This has been a killer feature for me, because there are many places where I want /specific/ HTML, and neither org-export nor pandoc will compile org plaintext the way I want (not unless I invest inordinate amounts of time futzing with templating systems). So I just hand-code HTML using those export blocks, and I'm /fine/.
There are also a couple of places where I use org-babel to call a shell script that updates an exported HTML block in-line. I use this trick to tweak a common HTML fragment (like email form) in one place and expand it into custom HTML, wherever I need to.
Ditto LaTeX, although I confess, I'm not a heavy user, so I almost certainly haven't faced the troubles you have. With HTML, however, I think what I have is just cromulent.
>I've recently converted my blog from org-mode to markdown.
Me too. I went to Jekyll and I thought I'd miss org but it turns out I don't. Plus I still get a slow lisp-like language (ruby) just like elisp.
Org is a neat idea but nothing supports it. You can get a jupyter-like experience with src blocks but have fun sharing it with anyone unless you only interact with other emacs users.
Markdown is merely acceptable, IMHO, but everything supports it, so it's the clear choice in my book.
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 paragraph), and supports only triple-backtick fenced preformatted text areas that just flip on and off.
Maybe the biggest change is that links are necessarily listed on their own line, proceeded by a `=>` and optionally followed by alt-text.
My gemtext parser is maybe 70 lines and it is arguably 95% of what one needs from Markdown.
I thought I was the only one. It is great for just having some text with headers and links, without any distractions.
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).
Definitely not common! Nice to hear I'm not alone either.
And yeah, I agree. Practically, it's the thing that annoys me the most day-to-day. I've mostly got wrapping set up to handle it now, but it remains a little finicky.
I don't think the lack of spec is holding Org back. Markdown came out in 2004; CommonMark came out in 2014. I think Markdown was already very popular by the time CommonMark came out.
The more obvious reasons are that Markdown was dead simple, unlike Org, and integrated into many popular products, unlike Org.
(Tangent: To be honest, I'm not sure why websites like Reddit opted for Markdown rather than text formatting buttons. It's a good thing, and I'm not complaining, but adding the standard rich text buttons (like the ones Reddit has now) seems like it would've been the more obvious move.)
You can say the same about Python. However, there the forces push in the opposite direction: Even when there are better pythony runtimes that provide almost identical behaviour (but better performance), everybody sticks to CPython.
I tried to use non-CPython just last week for the first time. The first thing I tried to install failed. When I looked up the error… I needed CPython.
In my limited experience, I can only assume people are sticking to CPython because it works. Speed doesn’t mean much if libraries and tools fail to function.
I've seen tons of non-cpython use, so I'm not really sure what claim you're trying to make. Aside from supporting "having a spec allows for many implementations that all work".
That's simply not true.
There are numerous android and iOS apps that support it.
There are implementations for Vim and other editors besides Emacs.
GitHub supports it, for example.
I have not found a satisfactory (to me) solution for note-taking in Markdown that is open-source, plain-text, and mobile-friendly with local (non-cloud) sync. (Except for maybe Logseq, which appears to be moving in the direction of using a database.)
I've used those apps and the problem is that they only support a tiny subset of the format, and they can't support any of the features that require the rest of emacs to be present which is a lot of of the value.
If you're okay with the stripped down version that's basically markdown but different and that's fine but I feel like most people fall in love with org mode because it's so powerful once you get it going and all that power comes from emacs. So I get the argument that it's no worse than markdown but you lose so much of the magic.
You have to read between the lines a bit, but the post supports it. It's talking about how readable it is, how you don't need tools, etc... and when it gets to tool support, it basically just has "you can use your mouse! you don't need to learn keyboard shortcuts!" to paraphrase, or if you prefer verbatim:
>The basic file open/save, finding help, exiting Emacs stuff is accessible with icons or the menu.
Or earlier:
>In contrast to that, the syntax of Emacs Org-mode as the one and only original form...
Because there is no other real option. Mobile org users overwhelmingly (AFAICT) use Emacs in Termux to edit their files.
This post was originally written in 2017 (tools maybe first in 2019? though it hardly matters). It's still true today.
Isn't that true of python as well? I would argue that Github's decision to use markdown for formatting, more than any other, is what resulted in its widespread adoption to other use cases. The simple tool to share code ate the world.
I'm continually surprised that Microsoft hasn't completely cornered the market on LLM code generation, given their head start with copilot and ready access to source code on a scale that nobody else really has.
For me, org-mode's big advantage over Markdown is org-mode's macro capability. For years I've been using emacs and org-mode to develop my online course book; each semester I export the then-current draft in HTML to post on the Web. I use lots of macros to expand text, evaluate emacs lisp expressions, etc.
Example: In an upcoming revision, I'm wrestling with what to call the book's model contract clauses, so {{{NOUN-C}}} expands to "Clause" or "Rule" or "Plan" or "Protocol" depending on my current vacillation state. Other macros include {{{NOUN-C}}} as components.
Example: At the top of the HTML page there's a date stamp as a macro that evaluates an emacs lisp expression.
I'm not posting a link here because the HN effect might bust out my (paid) usage limits at my host, site44.com. That's a great hosting site, by the way, with terrific support by one of its two people (founders, I'd guess). It automatically syncs a dedicated folder I maintain on Dropbox, so all I have to do is save changes to that folder and seconds later the change shows up at the online version.
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\*.
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.
That was some bad luck. I made an edit seconds after the post came rendered to get the formatting right. (On HN I expected to have to type \\\* to render \* but you just have to type \\*)
I understand your use case, I just think it makes it not worthy of comparisons to markdown.
I've used the following, in addition to the "escape character" method (which is officially documented as the other commenter noted):
For in-line escaping, I use tilde-blocks ~ ~ ... as in ~~ . This type-sets in monospace (code format) in exports, which usually* is what one wants anyway, viz. to demarcate the symbol as being symbolised.
This summary is definitely useful as I'm myself a user of Org. I still think backslash escaping doesn't get to be annoying, and is a simple algorithm, which is important when you want to paste text into your org documents from other sources.
You can keep these tricks in mind while writing, but sometimes it's not you doing the writing. It could be pasted text, it could be a machine writing.
So you can type *word* without it becoming bold? So an article can contain: "The logs come to about ~300 lines once you start the server with ~systemctl start fnord~"
The `code` equivalent in Org is ~code~. How do you type that without the Org highlighting removing the ~ from "~300 lines", thinking that the code snippet begins there? This is an example I got from grepping my org files for U+200B.
I use org a lot, in fact, it's my daily driver. I also have to deal with MySQL, and, if using the vertical output (what you get if you finish a query with '\G' instead of ';' it makes pasting into an org file a pain.
Sure, not a big pain, I just wrapped it in a function paste-from-mysql that appends the whitespace, but then I need to take out the whitespace of I want to paste that somewhere else. It would be nice to have org support some sort of 'do not interpret what comes next' block markers. I guess someone with enough time and skills could make this change but, alas, that's not me.
In an Org document that contains Org examples (e.g. if this article had been written in Org), even Emacs gets confused about rendering it. So you might find that sections in example text are evaluated as being part of top-level sections and collapsing is wonky, etc.
I run into this a lot with gptel. I use a main Org file for all my daily notes, and since gptel streams LLM output as Org (which is good), it conflicts with my main file. I have a post-processing function that converts headings into `#` to avoid this, but it's a hack I'd rather not do.
For me the thing keeping me on markdown is Obsidian on mobile - no other note taking app comes close. If they made an actual Emacs for mobile (actual emacs complete with elisp support, not the existing org mode apps) that was a pleasure to use, I would likely switch to that.
As it is, the * vs # for headings makes switching between the two uncomfortable.
Happy Journelly user here! Finally a great place to store notes/links on my iPhone in a simple but powerful app for rediscovery. That I can bring to my windows / Linux / Mac eMacs.
Btw, which other note taking apps worth talking about exist? I am aware of org-roam and scimax (?) and both look promising but I find that (at least for org-roam) there’s not enough big picture explaining what is going on behind the curtains. That somewhat discouraged me from spending a lot of time with it, but a quick glance did look promising.
org-roam is a very small and stable codebase, worth reading on its own simply for education, but I also find that if you're interested in the internals, it's pretty accessible.
I have used Emacs on mobile for years. Works great in Termux on Android for instance. I use it daily and with the same .emacs.d (synced using git) as I use on computers, with just a few conditionals in init.el to not load too many bloated dependencies for things I am unlikely to use on my phone anyway.
I can second this, Termux + Emacs turned my phone back into a personal computer.
It is helpful to add extra keys to your touch keyboard, which you can do by editing your termux properties file (see https://wiki.termux.com/wiki/Touch_Keyboard). Helpful when you don't have a hardware keyboard available.
> an actual Emacs for mobile (actual emacs complete with elisp support, not the existing org mode apps)
There is an official fully graphical Emacs for Android (not just the terminal version in Termux).
> that was a pleasure to use
Oh... Well, it will probably get better in time, as new features are added. For now, it actually works great with an Android tablet of 8" or more and a bluetooth keyboard. The small screen of a phone doesn't lend itself well to Emacs's interface.
All well and good, but some Org Mode markup symbols are badly chosen if the purpose is human-to-human communication, and that is a profound demerit for a system that purports to structure and facilitate human-to-human communication. Most notably, asterisks are not good section headers. Pound signs are.
So people are not going to switch from Markdown for most purposes. It feels really wrong. And they will generally prefer one system.
YMMV obviously, some people have an easier time managing polyglot systems. But if the goal is to have One System, it won't be Org Mode. It'll be some version of Markdown. Perhaps Org Mode reskinned to look more like Markdown.
What's cool about Org isn't the symbols, but the semantics of a tree with tags, TODOs (along agenda & scheduling), and code blocks.
Org had the problem that a single implementation gained too many features and went underspecified, making the language unusable outside of emacs.
Markdown has the reverse problem, lots of implementations with variance that leave you with the lowest common denominator (there's specs, but IMO having many specs is pretty much having no spec, just many implemenattions)
It'd be cool to see a language that standardised Org features, but tried hard to keep things readable/compatible with markdown.
Good outline of capabilities; one of the few in the comments! The tree with tags part is super interesting. I'm using beads more and having short codes for tickets is something I want my mark up to be better at, want to integrate.
I mention this, because I am not particular about which character symbolises what as long as it is consistent and documented.
However, some people do want things to look just so, and for them, few tools come close to Emacs orgmode.
One can certainly reskin the plaintext rendering to show up however one wants. This has the downside of "two systems" though, e.g. type ** but see it insta-rendered as ###. Although, I rarely type headings like that (character by character). I use the keybindings to "make header", "indent", "de-indent" etc.
Precisely. Emacs folks often talk about how incredibly powerful and flexible their system is, so working with a reskinned Org Mode markup system when dealing with other people's stuff should be completely trivial for them, right? They should consider accommodating less technically sophisticated people for whom different notations are a bigger burden, no?
Given pandoc, as well as Emacs export tools if you stick to a minimum, you generally can move between a lot of formats freely. If I live in org mode for work tracking, I can also be in README.md trivially.
Using parentheses to delimit the URL is one thing I don't like about markdown, since parentheses are valid in URL curly braces or angle bracket would have been a better choice.
I love org mode and used eMacs for years. I felt like I had to switch to neovim and thus markdown for lots of reasons. Overall neovim has been a better experience for me but I do miss org mode.
It is [0]. All the pages are generated from org sources. If you scroll to the bottom of any page there is a link. Also tec used to have an overlay that would show you the org source directly, but ultimately it was decided that it should not be enabled because it required javascript and could be confusing.
Looking at the markup of some pages, such as https://orgmode.org/Changes.html , at least parts of the website seem to have been generated from Org mode.
There are attempts to extract it but I'm not sure any are successful. org mode is so tightly intertwined with Emacs features. For example tables can have calculations where the expressions are implemented in emacs lisp and can use emacs calc functions
org babel, which allows execution of code in blocks on the page and communication between them requires Emacs's comint (command interpreter) which would need to be ported to whatever application "displays" the text.
Folding and unfolding headlines requires the exact same display features that emacs has.
In general it seems the link is so tightly bound that it would be as well to simply embed Emacs in an application rather than extract org mode from it.
And yet an accessible ecosystem of 3rd party non-emacs tooling has not been developed.
I would pay big bucks for an obsidian-styled org-mode clone that had a no-frills GUI interface. I find org-modes task tracking, calendar, and agenda views top tier.
For what it's worth, there is this vscode extension https://github.com/realDestroyer/org-vscode/ which is pretty neat and can do org-mode task tracking, calendar and agenda view--and HTML preview.
Hmm with the way people go on about it I always assumed there was more to Org mode than "Markdown for Emacs", but this post makes it sound exactly like that.
He's also not exactly gaining credibility with "Markdown is useless because it's not standardised; there are lots of slightly different implementations"... Well yeah that's mildly annoying but it's still very useful! And then he completely throws away all credibility with "this isn't a problem with Org mode because Emacs is the only implementation!".
Can anyone tell me an actual reason to use Org mode over Markdown?
> I always assumed there was more to Org mode than "Markdown for Emacs", but this post makes it sound exactly like that.
That is because the post focuses on org-mode: the markup language. But there is also org-mode: the agenda tracker, org-mode: the literate programming system, org-mode: the spreadsheet, org-mode: the website publishing system, org-mode: the document writing system, org-mode the time-tracking system, org-mode: the personal wiki, etc.
>Can anyone tell me an actual reason to use Org mode over Markdown?
I think the reason in general is simply that org-mode is better, i.e. more carefully defined. I'll mention the things I like more specifically:
- Link syntax in markdown is something I never remember how it goes. Org-mode is [[link][description]].
- Text styles in org-mode make more sense. In markdown, * is used for italics, * for bold. Additionally, * is for lists, which might be confusing.
- Markdown blocks are freaking awful and seem to work by luck more than anything else. Code blocks even worse -- they are made by indenting 4 spaces or a tab! I couldn't come up with a worse way to do that even if I tried. Org-mode has clear #BEGIN_xxx / #END_xxx blocks.
- Markdown has a weird YAML frontmatter syntax. Org-mode has keywords which can be attached to the whole document and properties, which can be attached to every heading.
> Link syntax in markdown is something I never remember how it goes
I can remember it fairly easily. [Link](url). Very unconvinced by this.
> Text styles in org-mode make more sense. In markdown, * is used for italics, * for bold. Additionally, * is for lists, which might be confusing.
* for lists is what I would naturally use so I think that's better than - (but Markdown actually supports both). I'll give you * for italics though. Definitely should have been bold.
> - Markdown blocks are freaking awful and seem to work by luck more than anything else. Code blocks even worse -- they are made by indenting 4 spaces or a tab! I couldn't come up with a worse way to do that even if I tried. Org-mode has clear #BEGIN_xxx / #END_xxx blocks.
Sorry but there's no way #BEGIN_xxx is better than ``` or 4-space indent.
> Markdown has a weird YAML frontmatter syntax.
It doesn't. That's some extension. Maybe Pandoc?
> Org-mode has tags.
Yeah they look kind of useful.
> Org-mode has timestamps.
Can't say I've ever remotely wanted that feature...
> 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).
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.
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.
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.
“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.
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.
I've been on this bandwagon for a long time! I proposed org as an interchange format for Productivity and PKM tools several years ago [0]. Org allows me to unify my bookmark manager with the rest of my PKM as well as to-do management in a way that I don't think is possible with markdown.
That said I think that AI is changing things as it becomes best practice to document and define everything in plain text for LLM consumption. Since the default text format is markdown (due to github and PKM tool support) more and more people are exposed to it as the one true markup language. So maybe the boat has sailed and org becomes another example of the better format that doesn't win out. OTOH LLMs slurp up org content just as easily as they do markdown, maybe more so given the richer syntax. So maybe there's still room for both?
Either way I think the losers are going to be Sharepoint, Confluence, Jira etc, maybe even wikis, ie all the non standard ways people have been documenting their work to date.
Like us org folks have been saying all along, just stick with plain text!
[0] https://braintool.org/2022/04/29/Tools4Thought-should-use-Or...
> "Either way I think the losers are going to be [...] maybe even wikis, ie all the non standard ways people have been documenting their work to date."
Org mode never touched ConnectedText for me; I'd probably still use it if the tool either had gotten open-sourced and/or taken over by a dedicated team (of professionals). Its pros were user friendlieness, powerful scripting, reliability, having an extremely good search functionality, and a small but dedicated community. In other words some things Org mode still has not. And getting text in and out was trivial.
Sadly, AFAIK, the dev threw in the towel after facing a refactorization of the code. Having single-dev complex applications is very seldom a sign of sustainability (SPOF).
And functioning wikis obviously implement standards; several of them can run on flat-file structures (e. g. TiddlyWiki). Org mode can or could run them as front-end. Et cetera.
I discovered and started using org-mode (and, as a result, Emacs) when I migrated from Evernote in '16. Today I use it for all my project, task and knowledge management needs, with some files going over 15MB in size. And I'm still loving it. Started out with headers only, and every time I wanted something more, it was always just there for the taking. Easy to use, and also crazy powerful. Can't think of anything else that exhibits both those traits at once.
How do you handle PDFs, images, HTML/rich text snippets? Asking because Evernote supported all of those. It’s what keeps me using that app, even though I cringe every time I open it.
OP here... I do all of these from Emacs orgmode, and more.
Ref. a presentation I did last year: https://github.com/adityaathalye/slideware/
- The org plaintext: `clojure-web-app-workshop-functional-conf-2025.org` (see the raw source for formatting directives and structure.)
- Live coding presentation delivered straight from my org source: https://www.youtube.com/watch?v=YEHVEId-utY
- The RevealJS handout presentation compiled directly from the same source (self-hosted, with images, text snippets, quotes, code snippets): https://www.evalapply.org/posts/clojure-web-app-from-scratch...
- The extended blog post for the same (I start off all presentations as longform thinking in org plaintext): https://www.evalapply.org/posts/clojure-web-app-from-scratch...
- I can also do LaTeX PDF and raw tex, for undergrad student "professor points" :D (See examples in the github repo --- the "n Ways to FizzBuzz in Clojure" presentation. Which also was a live coding demo: https://www.youtube.com/watch?v=BTouODWov-A ... "demo live, or die trying", I say :D)
And... I mentioned my site... This is the build step, no Emacs needed :)
I've never used anything but plain text in org TBH. I know there are tools out there that make it possible/easy to work with certain binary files, but I've just never had such a use case. At most I'll put a link to a given file that opens it in a native viewer.
you can show images in org. https://orgmode.org/manual/Images.html
with webpages I just store the link, but maybe you want to download them? I've used singlefile extension to download and store copies and link from org.
with pdf I just store evince /path.pdf & and triple click to select and middle click in a terminal.
I've started using org-mode couple of years ago, and write documents using the basic features like headers and formatting, links between docs, and code sections, but still haven't figured out which power features are the ones worth investing time into, and would be the most useful. Which further features would you recommend digging into, based on your experience?
I suspect this is an issue for most org-mode users, we all use different things.
I have two real uses for org-mode; I write a "work log", or "diary", every day I'm at work which keeps track of meetings, tickets/issues I work on, pull-requests I review, etc.
Unrelated to that I have a property I rent out, and I keep a table for each year showing rent-received from my tenant. I have a little "database" of previous tenants, and their details.
When I add a new table row for this year, say "January 2026 | Sharon | €1000", that updates the global profit/loss table for the document as well as profit/loss for the current year AND a t able which just lists the tenants I've known, how much they paid, and how many months they rented for.
Both of these two use-cases use very different things. The diary is just a text-block as template, the financial stuff uses multiple tables, custom elisp code, and some summing operations.
I consider myself little above basics even after all this time. The features I use depend on what I'm doing at the time, and so I take a JIT approach to learning org-mode. I'd say just keep the main resources close by as they're very detailed, and search them whenever you're thinking of doing X thing.
A lot of the features in org simply aren't adding a ton of utility, IMHO.
If you need to represent tabular data, possibly with rudimentary calucations, in plain text then it's great.
For anything more complex it's best to just reach for Excel.
>some files going over 15MB in size
Word count ~3 million? (~60 novels worth!)
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.
The value of Org outside Emacs would be the same value that Markdown has, if it had wider adoption. Voit's post makes a strong argument for Org syntax's ability to serve for all the things Markdown currently does, while being more consistent and concise than Markdown, and so he pushes for it to be more widely adopted. We know that in tech, the better format doesn't always win at first, or ever, but we can advocate!
org-mode is just much more complicated to implement though and just contains so much. it's also a todo app. It also lets you run code like a python notebook. it can show you your tasks in a calendar.
I've used "org-mode" todo apps on android, but people complain they can't really use it because it doesn't implement everything.
The advantage of the core markdown syntax is that you know it works everywhere and it works everywhere because it's small and easy to implement.
1 reply →
Fair enough. We can argue about the betterness of org but even if so, its enough better enough to push our something as popular as Markdown. The real item of value is org mode.
1 reply →
I use Markdown for all my books, currently. It used to be a custom XML format, but that was really annoying to type even with custom Vim keybindings.
I do wish Markdown were more capable, but it's a good lowest common denominator for HTML and PDF. Also Pandoc-flavored markdown is pretty decent.
My current flow is:
Markdown -> preprocess -> pandoc -> HTML
Markdown -> preprocess -> pandoc -> HTML -> page-splitter -> split HTML
Markdown -> preprocess -> pandoc -> LaTeX -> PDF
That last one is slow, and I'm hoping to replace it with Typst, probably:
Markdown -> preprocess -> pandoc -> docbook -> xlstproc -> typst -> PDF
I've tried other things like Sphinx and it's tough to find something that checks all the boxes I need.
In general, though, I'm pretty impressed with Typst. I wrote a test program that takes the XML output from cmark-gfm and converts it to Typst with xsltproc. It produces PDFs in orders of magnitude less time than Pandoc/LaTeX. I use that now for all my casual PDF documents. https://github.com/beejjorgensen/xml2typ
> I'm hoping to replace it with Typst
This might be stupid but is there a reason you want to go through docbook and xsltproc instead of setting --pdf-engine=typst?
Looks like it's getting there, but still needs some work. It's not obeying the book output or number sections. I can probably get the indexing going, though.
Measured at 10x faster than LaTeX.
Yes. Two reasons:
1) More control over the typst output... 2) I didn't know you could do that. :D :D :D
I'll check it out--thanks for the pointer!
Repo is nice, thanks. Small nit: it would be nice to have included the final PDF output of your tool on `test.md` in the repo.
I've been using Org Mode for organizing my life in plain text for the past 10 years now.
Beorg on iOS [0] makes it great. I've also started using things like org-ql [1] and org-super-agenda [2] to make me even more productive.
I also have a daily log org file I use at work. It helps me keep track of what I need to do and what I've done. It makes yearly reviews easier as well!
[0]: https://www.beorgapp.com/
[1]: https://github.com/alphapapa/org-ql
[2]: https://github.com/alphapapa/org-super-agenda
Hi @cyrialize , Hopefully this is an acceptable level of self-promotion. It sounds like my browser extension, BrainTool might be useful in your workflow. It's kindof a bookmark/tab management tool. It syncs to a .org file and allows you to do things like mark tabs as a TODO, which you can then track in org-agenda etc. There's some brief descriptions and videos here: https://braintool.org/2025/09/16/Browser-Workflows-with-Brai...
Oh wow this looks really awesome! I'll have to check it out.
I unfortunately primarily use Firefox, but still this is great. I've manually tried to keep track of bookmarks via org, but of course I'll always forget to update it.
I’ve looked into a log/journal date tree approach with my various activities across the day (meeting notes, independent work notes, etc) under the date. But then I prefer being able to look through headings that anchor on context first, then dates second (/eventually).
Does your daily log link to other parts of one org file, or other org files?
I’ve asked LLMs their opinions. But curious for yours!
Also thinking about trying denote. The filenames begin with dates, then use tags/keywords to keep the thread on recurring topics.
My daily log file basically looks like this:
* Year
* Month
** Day
For example: * 2025
* January
** Saturday 01/10/26
In each day heading I'll have either a short note (like saying what meeting happened), or a link to a separate org file.
I keep an org file for each JIRA ticket I'm working on, so I'll link it out there. The presence of a link indicates that I've worked on that ticket that day.
Then in each individual ticket file I'll just keep top level day headings with notes of what I've done on the ticket, as well as other headings.
For example, an org file for a ticket would look something like:
* PR 1
#+BEGIN_SRC markdown
I like to pre-write up my PRs in a doc block in markdown in org mode just to use my keybindings. I copy-paste when I create a PR.
#+END
* Monday 01/01/26
- Started work on this today, figuring out where in the codebase to touch
- Straightforward, got a PR out
When I need to find something, I use something like consult-org-heading or consult-outline or consult-line.
1 reply →
I highly recommend just trying out org-mode and seeing what works best for you.
There are so many things built into org-mode and so many tools built around org-mode that you'll be able to find something that feels comfortable.
My other comment describes what I currently use, but I only really got there after trying out a bunch of different things after a while.
Sure.
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.
Are you suggesting I should pick the markup format for my private files according to the perceived popularity of another format?
I'm not sure what's your point. Are you telling people who use org-mode that they shouldn't?
If you think you'll ever want to use third-party tools to process that markup, or if some of your private files will transform into public files at some point, then yes, considering popularity makes a lot of sense.
If they're just text files you edit raw that will never interact with anything else but your text editor, then of course popularity doesn't matter at all. But in my experience, my use cases tend to expand over time.
The article even talks about org mode's interoperability, mainly about the fact that pandoc supports it. And then bizarrely ignores the fact that it has much less ecosystem support than Markdown. So this is very much a subject the article itself brings up, and something that therefore also deserves to be critiqued.
6 replies →
No? I’m pushing back against advocacy for broader adoption of org mode beyond personal file markup though, which is what I feel like this piece is arguing.
> note that this is not about Emacs at all. This is about Org mode syntax and its advantages even when used outside of Emacs.
One of the advantages of "going with the flow" when you can is that you benefit from numbers. You're a market of one, but by "going with the flow" the total market is huge.
Even if for me personally 185V mains power would be better, I can't buy gear for 185V, none of the electricians around here know how to work with it, the cables and sockets and everything else are defined around the prevailing systems at 220-250V here.
Maybe in my kitchen a 520mm dishwasher would be great, but alas dishwashers you can buy here are 600mm or 450mm ("slimeline") models, so 520mm isn't available.
With my poor hearing 14-bit PCM would be absolutely fine, but Sony's "Compact Disc" used 16-bit so that's what everybody uses and records by default.
If you work with Markdown, there are a lot of existing tools which are ready to use. There are tools for Org Mode, but maybe not as many.
There's definitely a sliding scale here. Refusing to use Twitter because it's full of Nazis is very different from refusing to conform to society's expectation that you wear clothes outside for example. There are people willing to spend most of their lives in jail because they refuse to wear clothes but almost all of us don't think that's a principle we care about enough to prioritise (also some of us get cold).
1 reply →
It's a matter of taste, isn't it? It's like LaTeX vs. Typst. You create the environment that works best for you.
In my experience, not really. I'd love to use Typst, you have no idea -- but when most journals require you to use their LaTeX template, then my personal taste doesn't really enter into the equation.
For personal workflows, yes. In your own backyard, you decide what side of the road you drive on.
But when building a product for other people to use - a messaging tool like slack or a commenting platform like GitHub code review…?
5 replies →
Markdown (subjectively) looks better than Org when it’s plaintext - postfix headers and dashed lists are annoying to parse but they distinguish sections visually. Org by comparison feels like a sea of asterisks.
(I am tickled by the /italic/ syntax though…)
I don’t like using “-“ for bullets and “*” for headings. I do love underlines for underlined text, slash for italics, and asterisks for bold. Other than that, po-tay-to, po-tah-to. Let’s all just pick one and use it consistently. I do agree with the argument that says “Markdown” is meaningless and you’re always forced to ask “What do you mean by that? Which flavor, exactly?” But that happens with anything “lightweight” as it is inevitably extended to deal with more complex demands and becomes more heavyweight in the process.
Markdown is worse than other formats in many ways. It has several ambiguities, there are significant variations between implementations, fairly basic features like tables, footnotes, strikethrough, etc. are "extensions" that aren't widely supported.
The only real advantage of markdown is that it is has because more ubiquitous/popular than others, possibly in part because it is relatively easy to implement, as long as you don't care that much about exact compatibility with other implementations.
This is advice that I would have rolled with pre-Generative AI.
Today, I'm not so sure. I'm actually way used to zim-wiki syntax because that's what I started off with; and already "moving it around" is becoming orders of magnitude easier given the ability to vibe-code tons of little scripts that make it work better with everything else -- and while this might seem a bit counter to the point -- I think one can reasonably rely on the idea of "market share isn't that important anymore compared to 'you, personally, should use the thing that works the best for you because translation will get orders of magnitude easier.'"
> This is advice that I would have rolled with pre-Generative AI.
/me laughs in pandoc
I'm surprised nobody else brought it up - what are the pros of left-hand driving? Is it about where the controls are in relation to handedness? Some sort of safety benefit? Better visibility in certain scenarios? And are postal carriers in America who drive LLVs getting the _best_ or the _worst_ of both worlds?
(I like to think about these sorts of things!)
I've driven both. Drove LHD for more than a decade in India. Now driving in RHD country for 2y now. Personally, I enjoy RHD more because I am right-handed and I get to do things easily with my RH. Otherwise, I realized that safety benefits comes from the driving discipline and not driving on a particular side of the road. Driving on Aus/Japan is way safer than India, despite all of them being LHD.
1 reply →
And here I am still carrying the torch for BBCode-alikes...
this is so true. i wrote a document in org and i'm still in the hospital after crashing into someone's markdown file
Markdown can be trivially embedded in org-mode, so no need to even miss out on that which "won sufficient share": * Org with md block #+begin_src markdown ..... #+end_src
Markdown may be a winner, but preferring it when org-mode exists is like tying both arms behind my back and trying to do serious things with my feet.
So like,
2 replies →
I’m not sure I see the benefit in that.
3 replies →
As long as we're telling people they should conform to what everyone else uses, why aren't you using Microsoft Word format instead?
We are talking about choosing a lightweight text markup language. Not choosing a file format for rich text files.
Expressing complex HTML or LaTeX constructs in org-mode is more complicated than writing the raw HTML or LaTeX. So for complex things, I'll always fall back to writing HTML or LaTeX directly. Markdown, instead, just falls back to HTML. Whatever I can't express in markdown, I can simply insert the HTML by hand. These markup languages are always fine for simple things, but have a hard time expressing more complicated things.
Perhaps some kind of escape mechanism, like typst, would solve this. But org-mode doesn't.
That said, org-mode-the-program (not org-mode-the-syntax) is just fantastic, and nothing else comes close. For me, this doesn't outweigh its problems. Obsidian is a good-enough alternative.
I've recently converted my blog from org-mode to markdown. 1000 lines of elisp, replaced with 200 lines of Python, and a 50x speedup. Last year, I did the same for my journal. I'm a bit sad to "leave", but it does simplify things.
Opposite day! I moved from markdown (hugo) to org plaintext built and rendered using a hand-rolled pandoc + bash site maker. No Emacs needed.
~350 lines of Bash, and it hot-builds, and it hot-reloads :)
https://github.com/adityaathalye/shite (README has GIF demos, and explains the design of the code)
Also, I use literal HTML exports in my org files, like this:
Which is neat, because when I `C-'` (M-x org-edit-special), it opens a temporary buffer with just the HTML, with the relevant syntax-aware editing mode turned on. This has been a killer feature for me, because there are many places where I want /specific/ HTML, and neither org-export nor pandoc will compile org plaintext the way I want (not unless I invest inordinate amounts of time futzing with templating systems). So I just hand-code HTML using those export blocks, and I'm /fine/.
There are also a couple of places where I use org-babel to call a shell script that updates an exported HTML block in-line. I use this trick to tweak a common HTML fragment (like email form) in one place and expand it into custom HTML, wherever I need to.
Ditto LaTeX, although I confess, I'm not a heavy user, so I almost certainly haven't faced the troubles you have. With HTML, however, I think what I have is just cromulent.
You can use code blocks for this and even specify the language so Emacs can provide proper syntax highlighting:
#+BEGIN_SRC html
#+END_SRC
If you are writing a technical document with a lot of code blocks you can have yasnippet to create the blocks for you by keyboard shortcut.
> Expressing complex HTML or LaTeX constructs in org-mode is more complicated than writing the raw HTML or LaTeX.
Eh? This makes no sense! You can embed any HTML and LaTeX easily in the doc. And you could since I encountered org over 15 years ago.
Since 2009 all my LaTeX and Beamer docs have been written in org. I lose nothing by using org.
> I've recently converted my blog from org-mode to markdown. 1000 lines of elisp, replaced with 200 lines of Python, and a 50x speedup.
I use Pelican which uses rst. But it was pretty trivial to write a plugin in Python to have it support org files.
>I've recently converted my blog from org-mode to markdown.
Me too. I went to Jekyll and I thought I'd miss org but it turns out I don't. Plus I still get a slow lisp-like language (ruby) just like elisp.
Org is a neat idea but nothing supports it. You can get a jupyter-like experience with src blocks but have fun sharing it with anyone unless you only interact with other emacs users.
Markdown is merely acceptable, IMHO, but everything supports it, so it's the clear choice in my book.
Its completely trivial to export orgmode to markdown either as a process or just whenever you copy to the clipboard.
Completely trivial isn't a big barrier to interoperation.
1 reply →
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 paragraph), and supports only triple-backtick fenced preformatted text areas that just flip on and off.
Maybe the biggest change is that links are necessarily listed on their own line, proceeded by a `=>` and optionally followed by alt-text.
My gemtext parser is maybe 70 lines and it is arguably 95% of what one needs from Markdown.
I thought I was the only one. It is great for just having some text with headers and links, without any distractions.
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).
Definitely not common! Nice to hear I'm not alone either.
And yeah, I agree. Practically, it's the thing that annoys me the most day-to-day. I've mostly got wrapping set up to handle it now, but it remains a little finicky.
AFAICT org-mode has no spec.
Still.
Decades later.
The only spec is a single implementation. Which is probably why approximately nothing else supports it.
CommonMark on the other hand is very widely supported and all of them work great together. I'll stick to CommonMark.
I don't think the lack of spec is holding Org back. Markdown came out in 2004; CommonMark came out in 2014. I think Markdown was already very popular by the time CommonMark came out.
The more obvious reasons are that Markdown was dead simple, unlike Org, and integrated into many popular products, unlike Org.
(Tangent: To be honest, I'm not sure why websites like Reddit opted for Markdown rather than text formatting buttons. It's a good thing, and I'm not complaining, but adding the standard rich text buttons (like the ones Reddit has now) seems like it would've been the more obvious move.)
There’s this https://orgmode.org/worg/org-syntax.html
You can say the same about Python. However, there the forces push in the opposite direction: Even when there are better pythony runtimes that provide almost identical behaviour (but better performance), everybody sticks to CPython.
I tried to use non-CPython just last week for the first time. The first thing I tried to install failed. When I looked up the error… I needed CPython.
In my limited experience, I can only assume people are sticking to CPython because it works. Speed doesn’t mean much if libraries and tools fail to function.
I've seen tons of non-cpython use, so I'm not really sure what claim you're trying to make. Aside from supporting "having a spec allows for many implementations that all work".
4 replies →
> approximately nothing else supports it.
That's simply not true. There are numerous android and iOS apps that support it. There are implementations for Vim and other editors besides Emacs. GitHub supports it, for example.
I have not found a satisfactory (to me) solution for note-taking in Markdown that is open-source, plain-text, and mobile-friendly with local (non-cloud) sync. (Except for maybe Logseq, which appears to be moving in the direction of using a database.)
There are several such solutions for Org-mode.
I've used those apps and the problem is that they only support a tiny subset of the format, and they can't support any of the features that require the rest of emacs to be present which is a lot of of the value.
If you're okay with the stripped down version that's basically markdown but different and that's fine but I feel like most people fall in love with org mode because it's so powerful once you get it going and all that power comes from emacs. So I get the argument that it's no worse than markdown but you lose so much of the magic.
1 reply →
Ah. Well that sure shuts down the "you don't have to use Emacs" argument.
You have to read between the lines a bit, but the post supports it. It's talking about how readable it is, how you don't need tools, etc... and when it gets to tool support, it basically just has "you can use your mouse! you don't need to learn keyboard shortcuts!" to paraphrase, or if you prefer verbatim:
>The basic file open/save, finding help, exiting Emacs stuff is accessible with icons or the menu.
Or earlier:
>In contrast to that, the syntax of Emacs Org-mode as the one and only original form...
Because there is no other real option. Mobile org users overwhelmingly (AFAICT) use Emacs in Termux to edit their files.
This post was originally written in 2017 (tools maybe first in 2019? though it hardly matters). It's still true today.
2 replies →
Codeberg supports Org for READMEs! I think some other Git forge does too, but the name escapes me ;)
So does GitHub since forever BTW
Isn't that true of python as well? I would argue that Github's decision to use markdown for formatting, more than any other, is what resulted in its widespread adoption to other use cases. The simple tool to share code ate the world.
I'm continually surprised that Microsoft hasn't completely cornered the market on LLM code generation, given their head start with copilot and ready access to source code on a scale that nobody else really has.
Python has a spec and multiple healthy implementations, and is overwhelmingly more popular than org mode, so I don't really think that's a rebuttal.
Honestly, "no spec" feels like more of a feature than a bug -- or more specifically, "proof of quality."
If it's gotten this far WITHOUT a spec, there's something inherently good going on that lets it keep going.
Would you say the same about markdown?
For me, org-mode's big advantage over Markdown is org-mode's macro capability. For years I've been using emacs and org-mode to develop my online course book; each semester I export the then-current draft in HTML to post on the Web. I use lots of macros to expand text, evaluate emacs lisp expressions, etc.
Example: In an upcoming revision, I'm wrestling with what to call the book's model contract clauses, so {{{NOUN-C}}} expands to "Clause" or "Rule" or "Plan" or "Protocol" depending on my current vacillation state. Other macros include {{{NOUN-C}}} as components.
Example: At the top of the HTML page there's a date stamp as a macro that evaluates an emacs lisp expression.
I'm not posting a link here because the HN effect might bust out my (paid) usage limits at my host, site44.com. That's a great hosting site, by the way, with terrific support by one of its two people (founders, I'd guess). It automatically syncs a dedicated folder I maintain on Dropbox, so all I have to do is save changes to that folder and seconds later the change shows up at the online version.
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\*.
Did you edit your comment? I was about to begin by saying I could not see how you escaped that, but now I see the backslashes.
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.
That was some bad luck. I made an edit seconds after the post came rendered to get the formatting right. (On HN I expected to have to type \\\* to render \* but you just have to type \\*)
I understand your use case, I just think it makes it not worthy of comparisons to markdown.
Yeah escaping can be annoying.
I've used the following, in addition to the "escape character" method (which is officially documented as the other commenter noted):
For in-line escaping, I use tilde-blocks ~ ~ ... as in ~~ . This type-sets in monospace (code format) in exports, which usually* is what one wants anyway, viz. to demarcate the symbol as being symbolised.
For non-code text blocks, "Literal Example" https://orgmode.org/manual/Literal-Examples.html This also gets typeset in monospace, in exports.
For special symbols, LaTeX-like syntax https://orgmode.org/manual/Special-Symbols.html
This summary is definitely useful as I'm myself a user of Org. I still think backslash escaping doesn't get to be annoying, and is a simple algorithm, which is important when you want to paste text into your org documents from other sources.
You can keep these tricks in mind while writing, but sometimes it's not you doing the writing. It could be pasted text, it could be a machine writing.
What's the use case for escaping its syntax? At top level it's just an arbitrarily nested list.
So you can type *word* without it becoming bold? So an article can contain: "The logs come to about ~300 lines once you start the server with ~systemctl start fnord~"
The `code` equivalent in Org is ~code~. How do you type that without the Org highlighting removing the ~ from "~300 lines", thinking that the code snippet begins there? This is an example I got from grepping my org files for U+200B.
6 replies →
I use org a lot, in fact, it's my daily driver. I also have to deal with MySQL, and, if using the vertical output (what you get if you finish a query with '\G' instead of ';' it makes pasting into an org file a pain.
Sure, not a big pain, I just wrapped it in a function paste-from-mysql that appends the whitespace, but then I need to take out the whitespace of I want to paste that somewhere else. It would be nice to have org support some sort of 'do not interpret what comes next' block markers. I guess someone with enough time and skills could make this change but, alas, that's not me.
2 replies →
In an Org document that contains Org examples (e.g. if this article had been written in Org), even Emacs gets confused about rendering it. So you might find that sections in example text are evaluated as being part of top-level sections and collapsing is wonky, etc.
I run into this a lot with gptel. I use a main Org file for all my daily notes, and since gptel streams LLM output as Org (which is good), it conflicts with my main file. I have a post-processing function that converts headings into `#` to avoid this, but it's a hack I'd rather not do.
2 replies →
Org mode is great for outline like documents.
Markdown is great for paragraph-like documents.
I've used both for a long time, and have found markdown to be a poor replacement for org-mode and org-mode to be a bad replacement for markdown.
If org more was as successful as markdown it would likely also have a lot of unstandardized additions.
Though at its current state, it wouldn't need that much more, because it can already do tons of stuff that markdown cannot even start dreaming about.
For me the thing keeping me on markdown is Obsidian on mobile - no other note taking app comes close. If they made an actual Emacs for mobile (actual emacs complete with elisp support, not the existing org mode apps) that was a pleasure to use, I would likely switch to that.
As it is, the * vs # for headings makes switching between the two uncomfortable.
I’ve built a handful of org based iOS apps.
While my initial intention was to bring as much org support to iOS as possible (https://plainorg.com), my thinking evolved over time and I gravitated towards a different kind of mobile-optimised experience, and so https://journelly.com was born. I’ve recently added Markdown support too https://xenodium.com/journelly-1-3-released
I use Journelly the most and is also my most popular app.
I have an org scratch pad and also a habit tracking app https://flathabits.com.
Happy Journelly user here! Finally a great place to store notes/links on my iPhone in a simple but powerful app for rediscovery. That I can bring to my windows / Linux / Mac eMacs.
Btw, which other note taking apps worth talking about exist? I am aware of org-roam and scimax (?) and both look promising but I find that (at least for org-roam) there’s not enough big picture explaining what is going on behind the curtains. That somewhat discouraged me from spending a lot of time with it, but a quick glance did look promising.
org-roam is a very small and stable codebase, worth reading on its own simply for education, but I also find that if you're interested in the internals, it's pretty accessible.
I have used Emacs on mobile for years. Works great in Termux on Android for instance. I use it daily and with the same .emacs.d (synced using git) as I use on computers, with just a few conditionals in init.el to not load too many bloated dependencies for things I am unlikely to use on my phone anyway.
I can second this, Termux + Emacs turned my phone back into a personal computer.
It is helpful to add extra keys to your touch keyboard, which you can do by editing your termux properties file (see https://wiki.termux.com/wiki/Touch_Keyboard). Helpful when you don't have a hardware keyboard available.
> an actual Emacs for mobile (actual emacs complete with elisp support, not the existing org mode apps)
There is an official fully graphical Emacs for Android (not just the terminal version in Termux).
> that was a pleasure to use
Oh... Well, it will probably get better in time, as new features are added. For now, it actually works great with an Android tablet of 8" or more and a bluetooth keyboard. The small screen of a phone doesn't lend itself well to Emacs's interface.
All well and good, but some Org Mode markup symbols are badly chosen if the purpose is human-to-human communication, and that is a profound demerit for a system that purports to structure and facilitate human-to-human communication. Most notably, asterisks are not good section headers. Pound signs are.
So people are not going to switch from Markdown for most purposes. It feels really wrong. And they will generally prefer one system.
YMMV obviously, some people have an easier time managing polyglot systems. But if the goal is to have One System, it won't be Org Mode. It'll be some version of Markdown. Perhaps Org Mode reskinned to look more like Markdown.
What's cool about Org isn't the symbols, but the semantics of a tree with tags, TODOs (along agenda & scheduling), and code blocks.
Org had the problem that a single implementation gained too many features and went underspecified, making the language unusable outside of emacs. Markdown has the reverse problem, lots of implementations with variance that leave you with the lowest common denominator (there's specs, but IMO having many specs is pretty much having no spec, just many implemenattions)
It'd be cool to see a language that standardised Org features, but tried hard to keep things readable/compatible with markdown.
Good outline of capabilities; one of the few in the comments! The tree with tags part is super interesting. I'm using beads more and having short codes for tickets is something I want my mark up to be better at, want to integrate.
I thought maybe neorg would be a counter-example, of something compatible. But it is its own format. Which has a specification repo! https://github.com/nvim-neorg/norg-specs/blob/main/1.0-speci...
> Perhaps Org Mode reskinned to look more like Markdown.
or, reskinned to look visually whatever one wants...
https://sophiebos.io/posts/beautifying-emacs-org-mode/
https://zzamboni.org/post/beautifying-org-mode-in-emacs/
I mention this, because I am not particular about which character symbolises what as long as it is consistent and documented.
However, some people do want things to look just so, and for them, few tools come close to Emacs orgmode.
One can certainly reskin the plaintext rendering to show up however one wants. This has the downside of "two systems" though, e.g. type ** but see it insta-rendered as ###. Although, I rarely type headings like that (character by character). I use the keybindings to "make header", "indent", "de-indent" etc.
Precisely. Emacs folks often talk about how incredibly powerful and flexible their system is, so working with a reskinned Org Mode markup system when dealing with other people's stuff should be completely trivial for them, right? They should consider accommodating less technically sophisticated people for whom different notations are a bigger burden, no?
4 replies →
Will a full complete org mode ever come to vim? A man can hope…
Edit: I wonder if the vim community can contribute to a feature bounty like this? Hmm
I added Evil Mode to my emacs and never went back to vim except for some quick edits in the terminal.
Given pandoc, as well as Emacs export tools if you stick to a minimum, you generally can move between a lot of formats freely. If I live in org mode for work tracking, I can also be in README.md trivially.
Using parentheses to delimit the URL is one thing I don't like about markdown, since parentheses are valid in URL curly braces or angle bracket would have been a better choice.
I love org mode and used eMacs for years. I felt like I had to switch to neovim and thus markdown for lots of reasons. Overall neovim has been a better experience for me but I do miss org mode.
Question: why is `https://orgmode.org/` in html and not in ... org mode?
It is [0]. All the pages are generated from org sources. If you scroll to the bottom of any page there is a link. Also tec used to have an overlay that would show you the org source directly, but ultimately it was decided that it should not be enabled because it required javascript and could be confusing.
0. https://git.sr.ht/~bzg/orgweb
Looking at the markup of some pages, such as https://orgmode.org/Changes.html , at least parts of the website seem to have been generated from Org mode.
Yeah, but still not org mode.
It would get more adoption if it wasn’t tied to the waist to emacs.
Markdown doesn’t require Vim.
There are attempts to extract it but I'm not sure any are successful. org mode is so tightly intertwined with Emacs features. For example tables can have calculations where the expressions are implemented in emacs lisp and can use emacs calc functions
org babel, which allows execution of code in blocks on the page and communication between them requires Emacs's comint (command interpreter) which would need to be ported to whatever application "displays" the text.
Folding and unfolding headlines requires the exact same display features that emacs has.
In general it seems the link is so tightly bound that it would be as well to simply embed Emacs in an application rather than extract org mode from it.
The only reason why Org mode doesn’t have twenty variants like Markdown is because no one uses it.
I love writing blog posts with org mode. I wrote a blog post about blog posting in org mode. https://justinhj.github.io/2020/03/09/how-to-blog-with-org-m...
I wrote some code that exports html to a Jekyll static site, but really it works with anything that expects html.
And yet an accessible ecosystem of 3rd party non-emacs tooling has not been developed.
I would pay big bucks for an obsidian-styled org-mode clone that had a no-frills GUI interface. I find org-modes task tracking, calendar, and agenda views top tier.
For what it's worth, there is this vscode extension https://github.com/realDestroyer/org-vscode/ which is pretty neat and can do org-mode task tracking, calendar and agenda view--and HTML preview.
What do you think about my orgmode obsidian plugin?
https://github.com/BBazard/obsidian-orgmode-cm6
Incredible work.
very nice. Keep up the good work.
Hmm with the way people go on about it I always assumed there was more to Org mode than "Markdown for Emacs", but this post makes it sound exactly like that.
He's also not exactly gaining credibility with "Markdown is useless because it's not standardised; there are lots of slightly different implementations"... Well yeah that's mildly annoying but it's still very useful! And then he completely throws away all credibility with "this isn't a problem with Org mode because Emacs is the only implementation!".
Can anyone tell me an actual reason to use Org mode over Markdown?
> I always assumed there was more to Org mode than "Markdown for Emacs", but this post makes it sound exactly like that.
That is because the post focuses on org-mode: the markup language. But there is also org-mode: the agenda tracker, org-mode: the literate programming system, org-mode: the spreadsheet, org-mode: the website publishing system, org-mode: the document writing system, org-mode the time-tracking system, org-mode: the personal wiki, etc.
>Can anyone tell me an actual reason to use Org mode over Markdown?
I think the reason in general is simply that org-mode is better, i.e. more carefully defined. I'll mention the things I like more specifically:
- Link syntax in markdown is something I never remember how it goes. Org-mode is [[link][description]].
- Text styles in org-mode make more sense. In markdown, * is used for italics, * for bold. Additionally, * is for lists, which might be confusing.
- Markdown blocks are freaking awful and seem to work by luck more than anything else. Code blocks even worse -- they are made by indenting 4 spaces or a tab! I couldn't come up with a worse way to do that even if I tried. Org-mode has clear #BEGIN_xxx / #END_xxx blocks.
- Markdown has a weird YAML frontmatter syntax. Org-mode has keywords which can be attached to the whole document and properties, which can be attached to every heading.
- Org-mode has tags.
- Org-mode has timestamps.
> Link syntax in markdown is something I never remember how it goes
I can remember it fairly easily. [Link](url). Very unconvinced by this.
> Text styles in org-mode make more sense. In markdown, * is used for italics, * for bold. Additionally, * is for lists, which might be confusing.
* for lists is what I would naturally use so I think that's better than - (but Markdown actually supports both). I'll give you * for italics though. Definitely should have been bold.
> - Markdown blocks are freaking awful and seem to work by luck more than anything else. Code blocks even worse -- they are made by indenting 4 spaces or a tab! I couldn't come up with a worse way to do that even if I tried. Org-mode has clear #BEGIN_xxx / #END_xxx blocks.
Sorry but there's no way #BEGIN_xxx is better than ``` or 4-space indent.
> Markdown has a weird YAML frontmatter syntax.
It doesn't. That's some extension. Maybe Pandoc?
> Org-mode has tags.
Yeah they look kind of useful.
> Org-mode has timestamps.
Can't say I've ever remotely wanted that feature...
Overall it seems like a wash.
But what's really gonna bake your noodle is the revelation that Emacs is one of the most reasonable ways to edit text.
We do not need another competing standard here. Markdown is adequate and more importantly widely adopted and growing.
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).
3 replies →
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.
2 replies →
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.
“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.
2 replies →
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.
markdown