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.
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!
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.
In the meantime, I'll advocate for evolving Markdown, specifically GFM.
I do use a custom keyboard layout, but that doesn't have to interoperate with anything/anyone.
Edit: I have a similar unpopular opinion: we should use functional languages and immutable datastructures. At least we some data of movement in that direction with the patterns being adopted by other languages and codebases.
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.
OP here. I stuck with orgmode all these years /because/ of the interoperability.
If I'm writing in Org, I can tangle / detangle between other plaintext sources, including source code. As well as export to collaborate.
The proposition is "yes, and", not "either / or".
It's /fine/ to switch to the popular "team" standard and stay there when needed. Several of my workplace documents, including wiki entries start off as local org-mode drafts. Once I'm okay to share, I export to markdown or draft wiki page and solicit comments. After that, if the document is for shared maintenance, I let my org-text alone, and switch to the "team" format.
This is perfectly fine.
That and the many kinds of markdown. I've been bitten enough by having to look up yet another poorly maintained document on how to markdown for /this/ particular app or website or utility, that I'd rather pandoc translate between my (sane, well documented, fully extensible) org text and whatever I need to share with others, than learn edge cases of various markdowns.
Sure, but I think it's safe to say Markdown has more interoperability, no?
Yes you can always use pandoc, but conversion usually brings quirks of its own. And more generally, the less conversion steps you need, the better.
If you just stick to vanilla markup, you don't encounter incompatibilities. The "many kinds of markdown" isn't an issue if you're not using platform-specific extensions in the first place. Which, usually, you're not, unless you need to do something very specific to that application.
Yes, more interoperability at the cost of capability.
Also, yes, conversion is quirky. That is why Org works until it does, and then I trade off being stymied by markdown's more plain-ness, in favour of collaborating with others.
And with vanilla markup, the trouble is that many applications /do not/ use just vanilla markup. People /invariably/ want "one key tweak" (like, front-matter or table of contents or footnotes or some such thing), and everyone ends up doing their own thing.
Perhaps the trouble with markdown is it's /too/ plain. So yes, lots of people can do lots of lowest common denominator stuff, but it does not extend to individuals wanting "just one thing" which also adds up to a lot of people.
Edit: a real-life example... I typically run code from org-mode for interactive testing and debugging --- the kind of stuff we write small throwaway scripts for.
In this one project, I made it so that /I/ or anyone else using org-mode could do it from org, for local development, and anyone else could just use the script as-is... including the CI pipeline.
Ahem. When I started with Markdown, I was regularly experiencing all the issues mentioned for years. The most popular format was Word (doc). Perhaps I should have stuck with that?
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).
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.
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.
GitHub has at least some support for org-mode rendering. Which is a good reminder that a lot of this stuff really doesn't have to be a stark either-or choice—a lot of standardization isn't inevitable or natural or necessary, but just a choice we happen to make, often for systemic reasons that aren't inherently justified (legibility/etc).
What if you're building a product for other people like you to use?
I think this is very common, like people building tools for trackers vs Ableton/Live/etc style DAWs, or those writing software only targeting the OS they use? Not every product is built with the goal of worldwide adoption.
Back to the specific case being discussed, I can easily export usable markdown from org. The people I share it with have never noticed it wasn't markdown since the start, so why wouldn't I continue to use org even when interacting with people who don't? It makes my private side of the exchange better for me, and it doesn't affect the public side negatively for others.
Yes, though in the case of driving, if I prefer driving on the left, I'd have to move, since I live in a country where you must drive on the right, but to use org-mode instead of markdown, I just ... use org-mode?
I'm afraid I don't understand your point here, sorry.
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.
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.
How does RHD make it easier to do things with your right hand?
I’m right-handed in a LHD country, and this means I used my right hand for almost everything. The gear selector, radio, climate controls, GPS… all done with my right hand. My left hand controls the turn signal, that’s about it. I think I’d have a very hard time with a RHD car where I need to be precise with buttons and touch screens using my left hand.
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.
Yep. I wouldn't like to see the result of embedding any org of reasonable complexity in md though, while I've embedded pretty complex md in org. And performed various operations on the whole thing, but now we're going from syntax to (Emacs) features.
Org is essentially the parent of _all_ other plaintext formats, and is able to treat them specifically at the native level. So for example there's a single command to run a code block, but the code runner is correctly resolved. And multiple blocks in different languages can communicate with each other. Entire projects can be placed in a single org files and still operate as though they're separate files. Literate programming is a breeze. Organization of anything is trivial.
The argument being made is not ‘org-mode is a reasonable alternative to a filesystem for organizing textual files’, it is ‘org-mode is a reasonable lightweight textual markup language’.
The fact you can replace entire project and documentation systems with org-mode is not an argument in favor of its lightweight text markup.
Yet text markup doesn't exist in a vacuum, heavy or light. Text is marked up in the first place so it can be better processed by a computer, while keeping it reasonably readable by humans. And there are a variety of markup formats out there as some given person gets the idea that doing it X way makes it most ideal for both use cases. Org-mode is a extremely lightweight, likely more so than md, AND allows for complex levels of processing WHILE maintaining that lightweightedness. The feature variety already exist as proof, at least in Emacs.
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.
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.
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".
Well, the original comment was implying org mode had limited popularity because there is no specification. I'm claiming cpython is way more popular compared to fe pypy because it has no spec. The typical scenario is: people try pypy. it mostly works but because of some weird problem some library is broken and then they give up.
Is the claim that pypy has no spec, but cpython does? By that definition I think either both have a spec (they both use https://docs.python.org/3/reference/index.html and both are just "an implementation") or neither has one (since neither fully specifies all behavior and all modules, which is probably true for ~all languages).
No. The claim is cpython has no spec. The link you posted is about the language.
The spec claim is about the behaviour of the runtime.
The underlying claim is hat pypy cannot succeed precisely because there's no clear definition of success/compatibility/compliance. The situation is completely different in the Java world. There there is a specification for the memory model, runtime, aso and you can be sure that when you switch between runtimes, it will just work.
Gotcha. Broadly agreed then (Java is a very good counter-example), though I think pypy might be succeeding quite a bit more than org-mode in terms of users... and org-mode doesn't have a language spec either afaict. It has a fairly good description of the current code's parsing behavior, but the closest I've seen to something rigorous is https://github.com/200ok-ch/org-parser and even that's still unfinished from the readme (and it seems probably abandoned).
I haven't looked into the actual current state of things though, my last check was a couple years ago. I'd be pretty happy if things have changed, I just haven't seen any sign of that.
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.
Both Orgzly-revived and Orgro support a lot more than a tiny subset of the Org format.
Do they support tangling of source code and export to all the formats that Emacs's Org-mode supports? Of course not. But they have all of what I expect for a knowledge-base on my phone, which is a lot more than Markdown was ever intended for.
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.
I did try Orgzly a bit (it's decent though a bit unique, definitely worth a try for anyone curious), but I ended up dropping it after finding out that what I had made in it wasn't compatible with some other thing (I think Emacs, but it has been a while). Possibly something covered in https://www.reddit.com/r/orgmode/comments/9q9mn6/any_documen... though that's more about the reverse direction.
But that kind of inconsistency has been my overwhelming experience with anything except Emacs. CommonMark stuff has been practically flawless every time by comparison (though "markdown" in general is absolutely not, that's an unspecified mess)
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.
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 see. Just gave it a try and backslash works as escape. Though also I'm probably unlikely to experience such issues myself as my Emacs theme shows formatting characters even after applying the formatting.
Still exports as <p>\~300 lines</p> (in case of an HTML export). In fact you could "escape it" with any character, the backslash isn't doing anything special, the formatting just doesn't trigger if there's no white space on one side. When I use Org I also do not have auto-formatting, as you do, but the highlighting would still be wrong. And it'd be masochistic to put up with that unless you've invested a lot into Org for other reasons.
Sounds to me like it's a shortcoming of the exporter then, to not remove the escape characters as appropriate. Though one would think others would've run into this issue and fixed it. Or perhaps you're missing some other prevalent alternative?
The highlighting corrects for me once I "escape" the "~300".
Isn't the aim to have the highlighting only apply to `~systemctl start fnord~`, and not have whatever you used to escape the "~300" appear in an export? Highlighting and exporting are 2 pretty distinct functions.
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.
Thanks! I had actually seen that, but didn't realize that org does remove the leading comma when you extract a block to paste it somewhere else, which is great, because it means I need one less function.
Now I just need to keep my paste function, but have it add a leading comma instead of a space, and I need to use example instead of src (not a problem for this use case since, even though I normally paste them into sql src blocks, the syntax highlighting isn't that useful.
You gave me a nice little task for a rainy day, thanks :)
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.
Hmm I'm still not seeing the issue. Why aren't the examples just lists under say an examples header? Or the LLM output? Maybe gptel is expecting output to be in a fresh file or at the top level? It should be a trivial fix to intent a level before inserting.
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.
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.
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.
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.
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?
Your wish is our command... I'd argue that Emacs package maintainers care a lot about usability, in general. This extends to when they craft a package for general use.
https://github.com/tvraman/emacspeak "the complete audio desktop" by our blind and sight-impaired friends, for our blind and sight-impaired friends (and others who must necessarily use speech interfaces)
If there is a specific kind of person's specific kind of text editing need, there's probably an Emacs package for that.
The real tragedy is how poorly Emacs itself is conveyed to people. Mouse-pointing etc. works just fine out of the box. And as the emacspeak package demonstrates, at its core, it is a very usable and humane piece of technology.
The problem isn't customising your editor to use the symbol you want, but to have a spec that allows freely sharing files back and forth without trouble.
Org has no specification other editors can follow (although people have tried adding support to other editors and also writing such a spec).
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.
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.
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?
>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...
> 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.
> And I don't think org-mode's babel features really exist in Markdown
I think the neatest part of org-babel is the source code block execution, & the various ways it supports for configuring output. This allows for org files to be "plaintext notebooks" (like jupyter in plaintext"). -- It's really surprising that this part is not more common.
More niche is the "babel" part of that: because the code blocks can take variables as inputs, and output values, this allows a polyglot notebook where values from e.g. Python get passed to R and plotted or so. -- Cute idea, although I've never found it too useful. The supported types are (unsurprisingly) limited, and the language support for code blocks is held together by duct tape.
(Even more niche is the noweb syntax for proper "literate programming". Which is mostly discussed about how awful it is to use in practice?)
Of course, org also has a long tail of neat features (like how each heading can have properties attached to it, as well as tags, and the task management that relates to this).
> It's really surprising that this part is not more common.
I think it is because of low Emacs adoption and other editors not having enough support.
The problem with polyglot notebook workflow is probably, that you can only use it well for small data, or at least not big data, because who wants to have a million lines of output suddenly appear in the buffer, only to then read them as input for the next language ... That would be a tremendous amount of computational overhead. And if we didn't have that, we would need a way to pass a proper value from one language to the other.
What I also like is, that you can define code blocks that are used as formulas for spreadsheets (tables) inside the document. That's quite powerful too.
> (Even more niche is the noweb syntax for proper "literate programming". Which is mostly discussed about how awful it is to use in practice?)
I don't find it very awful to use. I have used that for working through computer programming books and it was fabulous.
I agree about the duct tape, which I also use often around the house, so maybe that's why I like org-babel :)
Just wanted to say that I share data between different blocks in different languages through files and env variables (I add :session shared to the src blocks that need to access this). That is useful also to have src blocks you can execute repeatedly and that depend on something like an aws identity being assumed (you just assume it in the first block that shares the session).
I agree it's messy, it's just a mess that works for me.
I think this is the crux of the issue, use like this is like a real program, just built up incrementally in a notebook rather than a repl or shell-with-pipes, and with manual error handling. The STEPS project was all about this- a way of incrementally building blocks that can be composed.
With org mode in mind, ideally you would have language support for this ie. Comments are scoped metadata that can be formatted, tested, linked etc.
You need a well defined spec like djot as a DSL for this to work, so that parsers can be easily written for it. This level of language support allows many different views onto the source code. We’re not there yet.
Babel features are kind of a moot point if you’re just talking about the syntax, which seems to be the purpose of the post. Most of the reason to use org mode is tied to emacs.
There’s no reason you couldn’t do something similar with markdown code blocks if someone were so inclined. But that’s tool dependent, not syntax.
I sort of agree with Karl’s point about there being too many standards of markdown, but I doubt org mode would have survived the same level of popularity without suffering the same fate.
It doesn’t help that there is no standard for org mode. You can only really use and take advantage of its power in emacs. It isn’t susceptible to lossy transformations because there’s only one real org mode editor.
Well, but I am not aware of anyone having come up with a good syntax to do babel things in Markdown. Markdown and Org Mode also set out to serve different purposes. For a quick and dirty text Markdown might suffice, but the babel stuff and spreadsheet stuff enable a lot of use cases that Markdown simply doesn't cater to. We already have the implementation of all these nice things in Emacs. If we were to replicate them for some markdown dialect, they would probably be done half-right, before someone actually manages to get literate programming right for various languages, including what code to translate to, how to wrap or not wrap the code that is inside blocks, sessions, output formats, etc. We might as well use what we have with Emacs. There is probably a way to call Emacs' functionality from outside of Emacs, to treat it as a library.
But not all is well with Org Mode syntax either. Many git hosters have only a very rudimentary implementation of a parser and writing a parser for it is not actually that easy. Its dynamic nature requires at least a 2 step approach of parsing and then later checking all kinds of definitions at the top of a file and further processing the document according to that. It's power comes at that cost. That's probably why we have so many Markdowns, but only one Org Mode (OK maybe a few, counting Vim and VSCodium plugins, that achieve a feature subset).
I will say though, that org mode syntax is much better suited for writing technical documentation than markdown. The only issue is, that not so many people know it or want to learn it, and I don't know a way to change that. Perhaps that effort to have the org mode syntax separately defined (https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Over...) by the same author will help creating more support for the format in various tools.
I agree you would need to specify the markdown to allow more implementations. https://github.com/jgm/djot Would make a good DSL inside languages, combine that with compile-time execution so that blocks can auto-recalculate and you have a more available mechanism than emacs/org in other languages.
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.
Is it though? Like for example, I often deal with Org-mode documents of several thousand lines of text and I honestly don't know any piece of software that can acceptably handle multi-thousand lines of markdown.
Emacs/Org-mode has tons of different ways to navigate and search through these large bodies - the outline nature of the structure is perfect for that - there's narrowing, collapsing/expanding, sparse-tree search, flexible sorting, indirect buffers, imenu, overlays and text properties that can render the text conditionally, etc.
I read HN and Reddit threads in Org-mode format¹; I browse my Jira board and tickets in Org-mode², I have Wiktionary lookup³ and Thesaurus⁴ - all in Org-mode.
Comparing Org-mode and Markdown and saying "Markdown is widely used [and thus it's better]" is wildly immature - popularity doesn't determine fitness for purpose - PHP is more widely used than Rust or Zig, but that doesn't make it "better" for systems programming.
I can agree, Markdown is adequate for relatively small documents like README files, but it's nowhere close to even try to compete with Org-mode in so many different aspects far beyond just the markdown format structure.
That’s awesome. Clearly, you are an Org format rockstar.
But be that as it may, if Markdown is inadequate for a variety of tasks, why do people use it for a variety of tasks? Your rebuttal is just “Here’s a task or two that I do that I think Org format is better for.” Fine. I don’t have an opinion about your tasks. I believe you that Org is better for those for you. But neither do those cases rebut the fact that MANY MORE people use Markdown quite successfully on a daily basis than Org for a wide variety of tasks (blogging, documentation, personal information management, etc.). Can Org also do those things? Yes, surely. Can Org do more than those things? Surely. But so can Markdown. So, if you want to say “Org format is better for ME and I can do more with it because it’s more feature full,” then I’d reply, “I’m sure you’re right.” But if you’re saying “Org is better for everyone,” well, then, the data just doesn’t support that.
And for the record I did not say that “Markdown is better.” You are putting words in my mouth. I said it was adequate for a wide variety of tasks. It works. It is sufficient. My proof for that is that it’s widely used for a variety of tasks. That’s it. Q.E.D.
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 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!)
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...
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.
Exactly. We should all speak/write Esperanto.
In the meantime, I'll advocate for evolving Markdown, specifically GFM.
I do use a custom keyboard layout, but that doesn't have to interoperate with anything/anyone.
Edit: I have a similar unpopular opinion: we should use functional languages and immutable datastructures. At least we some data of movement in that direction with the patterns being adopted by other languages and codebases.
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.
I also have a bunch of different org files for work and personal use.
For example, I have a file called tracker.org that is just for recurring habits/tasks that I set up with org-schedule.
I've thought about writing up a blog post about how I use org-mode, since I've been using every day for at least 8 years.
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.
OP here. I stuck with orgmode all these years /because/ of the interoperability.
If I'm writing in Org, I can tangle / detangle between other plaintext sources, including source code. As well as export to collaborate.
The proposition is "yes, and", not "either / or".
It's /fine/ to switch to the popular "team" standard and stay there when needed. Several of my workplace documents, including wiki entries start off as local org-mode drafts. Once I'm okay to share, I export to markdown or draft wiki page and solicit comments. After that, if the document is for shared maintenance, I let my org-text alone, and switch to the "team" format.
This is perfectly fine.
That and the many kinds of markdown. I've been bitten enough by having to look up yet another poorly maintained document on how to markdown for /this/ particular app or website or utility, that I'd rather pandoc translate between my (sane, well documented, fully extensible) org text and whatever I need to share with others, than learn edge cases of various markdowns.
Sure, but I think it's safe to say Markdown has more interoperability, no?
Yes you can always use pandoc, but conversion usually brings quirks of its own. And more generally, the less conversion steps you need, the better.
If you just stick to vanilla markup, you don't encounter incompatibilities. The "many kinds of markdown" isn't an issue if you're not using platform-specific extensions in the first place. Which, usually, you're not, unless you need to do something very specific to that application.
Yes, more interoperability at the cost of capability.
Also, yes, conversion is quirky. That is why Org works until it does, and then I trade off being stymied by markdown's more plain-ness, in favour of collaborating with others.
And with vanilla markup, the trouble is that many applications /do not/ use just vanilla markup. People /invariably/ want "one key tweak" (like, front-matter or table of contents or footnotes or some such thing), and everyone ends up doing their own thing.
Perhaps the trouble with markdown is it's /too/ plain. So yes, lots of people can do lots of lowest common denominator stuff, but it does not extend to individuals wanting "just one thing" which also adds up to a lot of people.
Edit: a real-life example... I typically run code from org-mode for interactive testing and debugging --- the kind of stuff we write small throwaway scripts for.
In this one project, I made it so that /I/ or anyone else using org-mode could do it from org, for local development, and anyone else could just use the script as-is... including the CI pipeline.
[1] https://gitlab.com/nilenso/cats/-/raw/master/README_TESTS.or... (notice that the gitignore procedure needed for this trick is self-executable from this org file itself, in addition to being self documenting)
[2] https://gitlab.com/nilenso/cats/-/blob/master/bin/curl-tests...
If I just stick to vanilla markdown, then I don't have features that I would really like in my notes, like tables, footnotes, etc.
Ahem. When I started with Markdown, I was regularly experiencing all the issues mentioned for years. The most popular format was Word (doc). Perhaps I should have stuck with that?
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).
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.
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…?
GitHub has at least some support for org-mode rendering. Which is a good reminder that a lot of this stuff really doesn't have to be a stark either-or choice—a lot of standardization isn't inevitable or natural or necessary, but just a choice we happen to make, often for systemic reasons that aren't inherently justified (legibility/etc).
What if you're building a product for other people like you to use?
I think this is very common, like people building tools for trackers vs Ableton/Live/etc style DAWs, or those writing software only targeting the OS they use? Not every product is built with the goal of worldwide adoption.
Back to the specific case being discussed, I can easily export usable markdown from org. The people I share it with have never noticed it wasn't markdown since the start, so why wouldn't I continue to use org even when interacting with people who don't? It makes my private side of the exchange better for me, and it doesn't affect the public side negatively for others.
There are whole countries that drive on the left
Yes, though in the case of driving, if I prefer driving on the left, I'd have to move, since I live in a country where you must drive on the right, but to use org-mode instead of markdown, I just ... use org-mode?
I'm afraid I don't understand your point here, sorry.
You cant even paste markdown into Slack, it’s embarrassing.
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.
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.
How does RHD make it easier to do things with your right hand?
I’m right-handed in a LHD country, and this means I used my right hand for almost everything. The gear selector, radio, climate controls, GPS… all done with my right hand. My left hand controls the turn signal, that’s about it. I think I’d have a very hard time with a RHD car where I need to be precise with buttons and touch screens using my left hand.
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,
Yep. I wouldn't like to see the result of embedding any org of reasonable complexity in md though, while I've embedded pretty complex md in org. And performed various operations on the whole thing, but now we're going from syntax to (Emacs) features.
I’m not sure I see the benefit in that.
Org is essentially the parent of _all_ other plaintext formats, and is able to treat them specifically at the native level. So for example there's a single command to run a code block, but the code runner is correctly resolved. And multiple blocks in different languages can communicate with each other. Entire projects can be placed in a single org files and still operate as though they're separate files. Literate programming is a breeze. Organization of anything is trivial.
The argument being made is not ‘org-mode is a reasonable alternative to a filesystem for organizing textual files’, it is ‘org-mode is a reasonable lightweight textual markup language’.
The fact you can replace entire project and documentation systems with org-mode is not an argument in favor of its lightweight text markup.
Yet text markup doesn't exist in a vacuum, heavy or light. Text is marked up in the first place so it can be better processed by a computer, while keeping it reasonably readable by humans. And there are a variety of markup formats out there as some given person gets the idea that doing it X way makes it most ideal for both use cases. Org-mode is a extremely lightweight, likely more so than md, AND allows for complex levels of processing WHILE maintaining that lightweightedness. The feature variety already exist as proof, at least in Emacs.
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.
Sure but each "completely trivial" step adds complexity to the overall process, which makes it brittle.
I'd rather just write in markdown than have to spend hours upon hours reading the awful emacs docs. I have a thousand things to do and no time.
Org might be better, but it's not better enough.
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.
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.
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".
Well, the original comment was implying org mode had limited popularity because there is no specification. I'm claiming cpython is way more popular compared to fe pypy because it has no spec. The typical scenario is: people try pypy. it mostly works but because of some weird problem some library is broken and then they give up.
Is the claim that pypy has no spec, but cpython does? By that definition I think either both have a spec (they both use https://docs.python.org/3/reference/index.html and both are just "an implementation") or neither has one (since neither fully specifies all behavior and all modules, which is probably true for ~all languages).
No. The claim is cpython has no spec. The link you posted is about the language. The spec claim is about the behaviour of the runtime.
The underlying claim is hat pypy cannot succeed precisely because there's no clear definition of success/compatibility/compliance. The situation is completely different in the Java world. There there is a specification for the memory model, runtime, aso and you can be sure that when you switch between runtimes, it will just work.
Gotcha. Broadly agreed then (Java is a very good counter-example), though I think pypy might be succeeding quite a bit more than org-mode in terms of users... and org-mode doesn't have a language spec either afaict. It has a fairly good description of the current code's parsing behavior, but the closest I've seen to something rigorous is https://github.com/200ok-ch/org-parser and even that's still unfinished from the readme (and it seems probably abandoned).
I haven't looked into the actual current state of things though, my last check was a couple years ago. I'd be pretty happy if things have changed, I just haven't seen any sign of that.
> 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.
Both Orgzly-revived and Orgro support a lot more than a tiny subset of the Org format.
Do they support tangling of source code and export to all the formats that Emacs's Org-mode supports? Of course not. But they have all of what I expect for a knowledge-base on my phone, which is a lot more than Markdown was ever intended for.
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.
Orgzly and Orgro can edit Org files on Android. (Orgro, also on iOS, along with other options.)
Both apps support Org-mode's scheduling, robust linking, and search features to some extent, features which don't exist at all in Markdown.
I did try Orgzly a bit (it's decent though a bit unique, definitely worth a try for anyone curious), but I ended up dropping it after finding out that what I had made in it wasn't compatible with some other thing (I think Emacs, but it has been a while). Possibly something covered in https://www.reddit.com/r/orgmode/comments/9q9mn6/any_documen... though that's more about the reverse direction.
But that kind of inconsistency has been my overwhelming experience with anything except Emacs. CommonMark stuff has been practically flawless every time by comparison (though "markdown" in general is absolutely not, that's an unspecified mess)
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?
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.
I wasn't sure how to do this, so I looked into it:
If you (setq org-pretty-entities t) below will render correctly in org buffers, and exports correctly too.
The logs come to about \tilde{}300 lines once you start the server with ~systemctl start fnord~
Here's a star: \ast
I see. Just gave it a try and backslash works as escape. Though also I'm probably unlikely to experience such issues myself as my Emacs theme shows formatting characters even after applying the formatting.
The following:
Still exports as <p>\~300 lines</p> (in case of an HTML export). In fact you could "escape it" with any character, the backslash isn't doing anything special, the formatting just doesn't trigger if there's no white space on one side. When I use Org I also do not have auto-formatting, as you do, but the highlighting would still be wrong. And it'd be masochistic to put up with that unless you've invested a lot into Org for other reasons.Sounds to me like it's a shortcoming of the exporter then, to not remove the escape characters as appropriate. Though one would think others would've run into this issue and fixed it. Or perhaps you're missing some other prevalent alternative?
The highlighting corrects for me once I "escape" the "~300".
You didn't understand me. The highlighting also disappears if you "escape" with %
Or the character A:Isn't the aim to have the highlighting only apply to `~systemctl start fnord~`, and not have whatever you used to escape the "~300" appear in an export? Highlighting and exporting are 2 pretty distinct functions.
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.
Have you tried literal examples?
https://orgmode.org/manual/Literal-Examples.html
Thanks! I had actually seen that, but didn't realize that org does remove the leading comma when you extract a block to paste it somewhere else, which is great, because it means I need one less function.
Now I just need to keep my paste function, but have it add a leading comma instead of a space, and I need to use example instead of src (not a problem for this use case since, even though I normally paste them into sql src blocks, the syntax highlighting isn't that useful.
You gave me a nice little task for a rainy day, thanks :)
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.
Hmm I'm still not seeing the issue. Why aren't the examples just lists under say an examples header? Or the LLM output? Maybe gptel is expecting output to be in a fresh file or at the top level? It should be a trivial fix to intent a level before inserting.
Karl Voit writes their articles in Org though, it even says so on the footer.
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.
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.
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.
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.
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.
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?
Your wish is our command... I'd argue that Emacs package maintainers care a lot about usability, in general. This extends to when they craft a package for general use.
https://github.com/tvraman/emacspeak "the complete audio desktop" by our blind and sight-impaired friends, for our blind and sight-impaired friends (and others who must necessarily use speech interfaces)
https://github.com/pprevos/emacs-writing-studio for writers at large
fountain-mode for screenwriting and playwriting https://fountain-mode.org/
https://chrismaiorana.com/emacs-guides/org-mode-syntax/ ("for writers and thinkers")
markdown beautification
https://www.reddit.com/r/emacs/comments/10h9jf0/beautify_mar...
https://oxal.org/blog/powerful-emacs-hacks-image-markdown/
general beautification
https://github.com/pretty-mode/pretty-mode
etc. etc. etc.
If there is a specific kind of person's specific kind of text editing need, there's probably an Emacs package for that.
The real tragedy is how poorly Emacs itself is conveyed to people. Mouse-pointing etc. works just fine out of the box. And as the emacspeak package demonstrates, at its core, it is a very usable and humane piece of technology.
Maybe I'll try it someday! I'm always up for an underrated, high quality life improvement technology.
The problem isn't customising your editor to use the symbol you want, but to have a spec that allows freely sharing files back and forth without trouble.
Org has no specification other editors can follow (although people have tried adding support to other editors and also writing such a spec).
There is a written-down specification, but not a formal grammar (I assume you implied the latter): https://orgmode.org/worg/org-syntax.html
The standalone project, org-parser is pretty good! https://github.com/200ok-ch/org-parser (usable from Javascript, Java).
See also: "Formal Specification and Programmatic Parser for Org-mode" https://www.reddit.com/r/emacs/comments/s0zvlh/formal_specif...
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.
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.
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.
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.
But what's really gonna bake your noodle is the revelation that Emacs is one of the most reasonable ways to edit text.
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
very nice. Keep up the good work.
Incredible 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?
>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.
> 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.
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).
> It's really surprising that this part is not more common.
I think it is because of low Emacs adoption and other editors not having enough support.
The problem with polyglot notebook workflow is probably, that you can only use it well for small data, or at least not big data, because who wants to have a million lines of output suddenly appear in the buffer, only to then read them as input for the next language ... That would be a tremendous amount of computational overhead. And if we didn't have that, we would need a way to pass a proper value from one language to the other.
What I also like is, that you can define code blocks that are used as formulas for spreadsheets (tables) inside the document. That's quite powerful too.
> (Even more niche is the noweb syntax for proper "literate programming". Which is mostly discussed about how awful it is to use in practice?)
I don't find it very awful to use. I have used that for working through computer programming books and it was fabulous.
I agree about the duct tape, which I also use often around the house, so maybe that's why I like org-babel :)
Just wanted to say that I share data between different blocks in different languages through files and env variables (I add :session shared to the src blocks that need to access this). That is useful also to have src blocks you can execute repeatedly and that depend on something like an aws identity being assumed (you just assume it in the first block that shares the session).
I agree it's messy, it's just a mess that works for me.
I think this is the crux of the issue, use like this is like a real program, just built up incrementally in a notebook rather than a repl or shell-with-pipes, and with manual error handling. The STEPS project was all about this- a way of incrementally building blocks that can be composed.
With org mode in mind, ideally you would have language support for this ie. Comments are scoped metadata that can be formatted, tested, linked etc.
You need a well defined spec like djot as a DSL for this to work, so that parsers can be easily written for it. This level of language support allows many different views onto the source code. We’re not there yet.
Babel features are kind of a moot point if you’re just talking about the syntax, which seems to be the purpose of the post. Most of the reason to use org mode is tied to emacs.
There’s no reason you couldn’t do something similar with markdown code blocks if someone were so inclined. But that’s tool dependent, not syntax.
I sort of agree with Karl’s point about there being too many standards of markdown, but I doubt org mode would have survived the same level of popularity without suffering the same fate.
It doesn’t help that there is no standard for org mode. You can only really use and take advantage of its power in emacs. It isn’t susceptible to lossy transformations because there’s only one real org mode editor.
Well, but I am not aware of anyone having come up with a good syntax to do babel things in Markdown. Markdown and Org Mode also set out to serve different purposes. For a quick and dirty text Markdown might suffice, but the babel stuff and spreadsheet stuff enable a lot of use cases that Markdown simply doesn't cater to. We already have the implementation of all these nice things in Emacs. If we were to replicate them for some markdown dialect, they would probably be done half-right, before someone actually manages to get literate programming right for various languages, including what code to translate to, how to wrap or not wrap the code that is inside blocks, sessions, output formats, etc. We might as well use what we have with Emacs. There is probably a way to call Emacs' functionality from outside of Emacs, to treat it as a library.
But not all is well with Org Mode syntax either. Many git hosters have only a very rudimentary implementation of a parser and writing a parser for it is not actually that easy. Its dynamic nature requires at least a 2 step approach of parsing and then later checking all kinds of definitions at the top of a file and further processing the document according to that. It's power comes at that cost. That's probably why we have so many Markdowns, but only one Org Mode (OK maybe a few, counting Vim and VSCodium plugins, that achieve a feature subset).
I will say though, that org mode syntax is much better suited for writing technical documentation than markdown. The only issue is, that not so many people know it or want to learn it, and I don't know a way to change that. Perhaps that effort to have the org mode syntax separately defined (https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Over...) by the same author will help creating more support for the format in various tools.
I agree you would need to specify the markdown to allow more implementations. https://github.com/jgm/djot Would make a good DSL inside languages, combine that with compile-time execution so that blocks can auto-recalculate and you have a more available mechanism than emacs/org in other languages.
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.
> it is adequate for a wide variety of tasks
Is it though? Like for example, I often deal with Org-mode documents of several thousand lines of text and I honestly don't know any piece of software that can acceptably handle multi-thousand lines of markdown.
Emacs/Org-mode has tons of different ways to navigate and search through these large bodies - the outline nature of the structure is perfect for that - there's narrowing, collapsing/expanding, sparse-tree search, flexible sorting, indirect buffers, imenu, overlays and text properties that can render the text conditionally, etc.
I read HN and Reddit threads in Org-mode format¹; I browse my Jira board and tickets in Org-mode², I have Wiktionary lookup³ and Thesaurus⁴ - all in Org-mode.
¹ https://youtu.be/ud3Gmxg5UZg
² https://github.com/agzam/go-jira.el
³ https://github.com/agzam/wiktionary-bro.el
⁴ https://github.com/agzam/mw-thesaurus.el
Comparing Org-mode and Markdown and saying "Markdown is widely used [and thus it's better]" is wildly immature - popularity doesn't determine fitness for purpose - PHP is more widely used than Rust or Zig, but that doesn't make it "better" for systems programming.
I can agree, Markdown is adequate for relatively small documents like README files, but it's nowhere close to even try to compete with Org-mode in so many different aspects far beyond just the markdown format structure.
That’s awesome. Clearly, you are an Org format rockstar.
But be that as it may, if Markdown is inadequate for a variety of tasks, why do people use it for a variety of tasks? Your rebuttal is just “Here’s a task or two that I do that I think Org format is better for.” Fine. I don’t have an opinion about your tasks. I believe you that Org is better for those for you. But neither do those cases rebut the fact that MANY MORE people use Markdown quite successfully on a daily basis than Org for a wide variety of tasks (blogging, documentation, personal information management, etc.). Can Org also do those things? Yes, surely. Can Org do more than those things? Surely. But so can Markdown. So, if you want to say “Org format is better for ME and I can do more with it because it’s more feature full,” then I’d reply, “I’m sure you’re right.” But if you’re saying “Org is better for everyone,” well, then, the data just doesn’t support that.
And for the record I did not say that “Markdown is better.” You are putting words in my mouth. I said it was adequate for a wide variety of tasks. It works. It is sufficient. My proof for that is that it’s widely used for a variety of tasks. That’s it. Q.E.D.
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