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.
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.
https://addons.mozilla.org/firefox/addon/copy-as-org-mode/ lets you copy formatted text from web pages to org-mode format
pdf's – do you mean downloading them? I mean, emacs can view pdf's, your computer can store them as files, making a clickable link to ./sicp.pdf from org-mode is just [[./sicp.pdf]] (or, while you're reading the pdf or browsing it in dired, hit your key for org-store-link and then in org-mode hit the key for org-insert-link).
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 :)
__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
}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.
Word count ~3 million? (~60 novels worth!)
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.
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.
So just implement the features it has in common with Markdown and add the rest as and when people ask for them.
For me, org-mode syntax is just that much more intuitive than Markdown. I sometimes feel that when devs invent something (Markdown, YAML, etc), they really should do 5 minutes of research before inventing their thing.
Markdown should have used all the org-mode syntax for the the features they wanted.
I don’t like many parts of markdown either (like the syntax for bold), but those were also IIRC already being parsed by some IRC clients before Markdown was specified.
News to me :-/
> So the author did do some searching to define the syntax.
I recall using tin/rtin in 1995, and people used the org mode syntax for italics, underline and bold (not that it made any difference). Same with plain-text email (I used elm, then pine, then mutt). Same with IRC clients - convention was the org mode syntax, not the markdown we have today.
The very first time I saw '**' for bold was in setext, circa 2004. People weren't actually using setext though; they were using *some text*, _some text_ and /some text/.
Here is a post from January 2001 documenting what the existing conventions were: https://everything2.com/title/conventions+for+plain+text
Here is the jargon file (maintained in the 90s by Guy Steele and ESR) that documented the the markup/typography conventions of the time: https://www.catb.org/jargon/html/writing-style.html
In short, no, I don't believe that the authors did any research. I think what happened is that they saw something like setext, though "great idea, lets run with that!", and did so.
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.
And I do come from the daily practice with Markdown and not academic arguments alone - which I also fancy, I have to admit.
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
This might be stupid but is there a reason you want to go through docbook and xsltproc instead of setting --pdf-engine=typst?
Measured at 10x faster than LaTeX.
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!
There's a reason you don't want generated data under version control.
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 mode never touched ConnectedText for me; I'd probably still use it if the tool either had gotten open-sourced and/or taken over by a dedicated team (of professionals). Its pros were user friendlieness, powerful scripting, reliability, having an extremely good search functionality, and a small but dedicated community. In other words some things Org mode still has not. And getting text in and out was trivial.
Sadly, AFAIK, the dev threw in the towel after facing a refactorization of the code. Having single-dev complex applications is very seldom a sign of sustainability (SPOF).
And functioning wikis obviously implement standards; several of them can run on flat-file structures (e. g. TiddlyWiki). Org mode can or could run them as front-end. Et cetera.
I tried to emphasize in my article that this is about orgdown, the syntax of Org-mode which itself is an Elisp implementation of a flexible tool.
So whenever you refer to tools like Sharepoint, Confluence, Jira, ... you're discussing tools and not lightweight markup languages and where Markdown has downsides nobody seems to know of which was the goal of my article.
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/
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.
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.
* 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.
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.
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.
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.
~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:
#+begin_export html
<form class="footer cluster"
action="https://buttondown.email/api/emails/embed-subscribe/evalapply"
method="post" target="popupwindow"
onsubmit="window.open('https://buttondown.email/evalapply','popupwindow')">
<input type="email" name="email" id="bd-email">
<span>
<input type="submit" value="subscribe">
<em>(thanks, <a href="https://buttondown.email" target="_blank">Buttondown</a>!)</em>
</span>
</form>
#+end_export
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.
#+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.
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.
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.
Completely trivial isn't a big barrier to interoperation.
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.
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.
What if I told you that your analogy breaks completely if you actually consider what Org-mode is. Think of Markdown as a noun (a thing) and Org-mode as a verb (a system that does things). It's like comparing HTML and React components - it's not about "preferable side of the road to drive", we're talking about a complete different mode of transportation - i.e., in a nation where there's infrastructure and roads for cyclists - the rules change from "drive on one side and obey traffic signs..." to be something different. Similar, yet different.
That's what everyone's missing when they try to compare Markdown and Org-mode, while looking at it only through the angle of the markup structure. Markdown is a markup - pure structure, no logic, no state, no content with behavior, no executable source blocks, no embedded logic - and that's the point.
Arguing which one should be "the default choice", is like saying - "just always drive a car, cars are more popular..." - an argument that has no sense whatsoever. If people find Org-mode useful (because it is), well, there's really not much you can do about it, right? Just like you can't tell people to prefer a bike, car, moto or a boat - each has pros and cons and suits different scenarios.
I'm not sure what's your point. Are you telling people who use org-mode that they shouldn't?
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.
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.
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.
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...
Well, then why aren't you using LaTeX? Isn't that more capable?
> And with vanilla markup, the trouble is that many applications /do not/ use just vanilla markup. People /invariably/ want "one key tweak"
And, that's going to be true as someone adopts it outside of Emacs, right?
Surely, someone will decide that the way Org Mode is doing something is wrong, right? They're going to do something like say, "Hey, why don't we permit Markdown style headings, too?" or something similar.
Or are you suggesting Org Mode military police? Felony markup possession?
There's nothing special about Org Mode that makes it immune to the problems you're describing. They will happen immediately upon wider adoption.
And if you somehow do stop it, well, it's tech. If you don't have a patent on it then someone will fork the idea and you'd have Borg Mode directly competing with you anyways.
Utility is Contextual.
“When you are hungry, eat; when you are thirsty, drink; when you are tired, sleep.” - Wise UNIX Master Foo
----
http://catb.org/esr/writings/unix-koans/shell-tools.html
Master Foo and the Shell Tools
A Unix novice came to Master Foo and said: “I am confused. Is it not the Unix way that every program should concentrate on one thing and do it well?”
Master Foo nodded.
The novice continued: “Isn't it also the Unix way that the wheel should not be reinvented?”
Master Foo nodded again.
“Why, then, are there several tools with similar capabilities in text processing: sed, awk and Perl? With which one can I best practice the Unix way?”
Master Foo asked the novice: “If you have a text file, what tool would you use to produce a copy with a few words in it replaced by strings of your choosing?”
The novice frowned and said: “Perl's regexps would be excessive for so simple a task. I do not know awk, and I have been writing sed scripts in the last few weeks. As I have some experience with sed, at the moment I would prefer it. But if the job only needed to be done once rather than repeatedly, a text editor would suffice.”
Master Foo nodded and replied: “When you are hungry, eat; when you are thirsty, drink; when you are tired, sleep.”
Upon hearing this, the novice was enlightened.
So, what does your comment to me say if used in response to your own org mode vs markdown comment you made in the post I responded to? You said org mode's capabilities are the reason why you don't want markdown.
You keep making this argument that org mode is just better, but you can immediately find a counterargument yourself to your own point.
Now, it's perfectly fine that that represents how you feel about the software. You can hold whatever opinion you want. But, you're not just trying to explain your opinion. You're trying to convince people that org mode is better. You understand why you're not being very persuasive in your argument, right? You've argued in a way that the only people who will agree with you are those that already hold the same opinion as you.
> note that this is not about Emacs at all. This is about Org mode syntax and its advantages even when used outside of Emacs.
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).
But when building a product for other people to use - a messaging tool like slack or a commenting platform like GitHub code review…?
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.
I'm afraid I don't understand your point here, sorry.
(I am tickled by the /italic/ syntax though…)
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.
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.'"
/me laughs in pandoc
(I like to think about these sorts of things!)
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.
Like you said, I enjoy LHD more where I can use my right hand for everything like radio/AC/GPS etc. and most of them work with muscle memory without even taking eyes off the road. Doing the same with my left hand while driving in India (LHT/RHD) is very tough.
The whole point of the article is that there is no Markdown. At least not a single instance from it. So when you're referring to Markdown, you're actually referring to a few dozens of slightly different markup languages which are hard to identify and except for a few, very tedious to convert.
In my opinion, this is far from being "reasonable".
Orgdown is explicitly mentioned only as one LML that doesn't come with the listed downsides of Markdown. So if you think that my article tries to convince you to use orgdown instead, you've missed the part where I say that there are many good alternatives of Markdown that do perform better when it comes to real world processes. I just tried to use orgdown as one example among many to state my point by showing an alternative. If you think that orgdown is the only one, you did not read the article carefully enough.
YMMV
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.
```org-mode
* this is org
```
?The fact you can replace entire project and documentation systems with org-mode is not an argument in favor of its lightweight text markup.
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.
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).
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.
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.
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.
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.)
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.
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.
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.)
There are several such solutions for Org-mode.
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.
> they only support a tiny subset of the format
I think Orgro's parser[0] is pretty complete at this point. If you can find an Org syntax that Orgro doesn't support, please let me know.
However I should be very clear here:
> 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
This is absolutely true and unlikely to change anytime soon. As I'm sure you know, parsing the syntax correctly is not at all the same as supporting all of the features built on top of the AST.
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.
>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.
Both apps support Org-mode's scheduling, robust linking, and search features to some extent, features which don't exist at all in Markdown.
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)
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.
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
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.
Looks like even the documentation for org-mode recommends using zero-width spaces: https://orgmode.org/manual/Escape-Character.html
I think org-mode was never primarily about its rendered output. Most users probably, like me, spend a lot of time (hours every day) in various org-mode documents, staring at what is essentially the raw mark-up. Org-mode in Emacs makes only a few minor changes to how the text is displayed, like hiding link targets, so you rarely look at the output. I export less than 1% of my org documents, so usually I don't care at all about what formatting renders like, as long as I get the mark-up correct enough that org-mode itself is functional (links can be followed, sections collapsed etc). The few documents I do want to export I can imagine using workarounds like the zero-width spaces, but it is not like there is often a need to have things looking like org-mode mark-up in the output.
For me at least, worrying about escaping mark-up would be too distracting and just add noise, as the raw mark-up is what I will read anyway. But I think some good way to escape things would not be a bad thing to have.
BTW there are verbatim blocks that can be used when you have entire lines of non-org content. And of course src-blocks. But that obviously does not handle every case escapes could be useful.
I understand your use case, I just think it makes it not worthy of comparisons to markdown.
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.
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
\~300 lines
The highlighting corrects for me once I "escape" the "~300".
%~300
A~300Sure, 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.
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 :)
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.
Orgdown already comes with more syntax elements that Markdown probably will ever get. So I do see a clear argument for the case that "unstandardized additions" to orgdown are less likely in addition to the fact that there aren't any.
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.
Edit: I wonder if the vim community can contribute to a feature bounty like this? Hmm
As it is, the * vs # for headings makes switching between the two uncomfortable.
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.
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.
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.
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.
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.
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...
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.
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.
Org has no specification other editors can follow (although people have tried adding support to other editors and also writing such a spec).
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...
It hurts me to read through the comments. One part of the people who commented obviously didn't read the article they're commenting on.
And another part of the commenters does mix up Org-mode, the Elisp implementation within Emacs, with orgdown, the lightweight syntax which is actually the topic of this article. This part of the discussion is totally missing the whole point of my article: practical issues related to Markdown; choosing any other LML which doesn't come with those downsides. Orgdown was just one example of many which I wanted to mention because it is one of the least known alternatives outside the Emacs bubble.
I extended the article accordingly and also answered to a comment that came via email.
HTH
And the differences that exist between implementations are there for a reason. Do you think chat apps would let you have headings or footnotes or whatever if they used org mode syntax? No, they don't want to give you those formatting options, so if they used org mode instead of Markdown, they'd just rip it out of there too. And now you have the same problem.
Markdown doesn’t require Vim.
https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool...
Tadaaaa!
Furthermore: Markdown requires a magic crystal ball to tell which Markdown flavor it actually is and how to process it for machines. Read the article.
Markdown would get more things done if it wasn't tied to the waist to chaos. ;-)
The purpose of the article is to make it a bit more transparent for people using Markdown-based tools that they still have some lock-in effects in place - depending how they are using one of the MD variants.
You're certainly right about the low level of popularity of orgdown. However, this was not the main purpose of the article and I made it very clear that there are many LMLs out there that do not come with the downsides of MD mentioned in the article. So even when you never ever touch org-mode or orgdown, this article is highly relevant to MD users. From that perspective, it's quite irrelevant if orgdown has caught on even though there are plenty of applications outside of Emacs that are able to use that syntax: https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool...
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.
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.
I wrote some code that exports html to a Jekyll static site, but really it works with anything that expects html.
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?
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.
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.
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.
Ok, I can give you that as a subjective thing you might have.
> or 4-space indent.
Ok, you saying this practically invalidates every single opinion you have on everything. So thanks for playing, I won.
Seriously though, you don't have to like org.
And I don't think org-mode's babel features really exist in Markdown? It's more like having python notebooks right in there (any language really).
I think the neatest part of org-babel is the source code block execution, & the various ways it supports for configuring output. This allows for org files to be "plaintext notebooks" (like jupyter in plaintext"). -- It's really surprising that this part is not more common.
More niche is the "babel" part of that: because the code blocks can take variables as inputs, and output values, this allows a polyglot notebook where values from e.g. Python get passed to R and plotted or so. -- Cute idea, although I've never found it too useful. The supported types are (unsurprisingly) limited, and the language support for code blocks is held together by duct tape.
(Even more niche is the noweb syntax for proper "literate programming". Which is mostly discussed about how awful it is to use in practice?)
Of course, org also has a long tail of neat features (like how each heading can have properties attached to it, as well as tags, and the task management that relates to this).
I think it is because of low Emacs adoption and other editors not having enough support.
The problem with polyglot notebook workflow is probably, that you can only use it well for small data, or at least not big data, because who wants to have a million lines of output suddenly appear in the buffer, only to then read them as input for the next language ... That would be a tremendous amount of computational overhead. And if we didn't have that, we would need a way to pass a proper value from one language to the other.
What I also like is, that you can define code blocks that are used as formulas for spreadsheets (tables) inside the document. That's quite powerful too.
> (Even more niche is the noweb syntax for proper "literate programming". Which is mostly discussed about how awful it is to use in practice?)
I don't find it very awful to use. I have used that for working through computer programming books and it was fabulous.
Just wanted to say that I share data between different blocks in different languages through files and env variables (I add :session shared to the src blocks that need to access this). That is useful also to have src blocks you can execute repeatedly and that depend on something like an aws identity being assumed (you just assume it in the first block that shares the session).
I agree it's messy, it's just a mess that works for me.
With org mode in mind, ideally you would have language support for this ie. Comments are scoped metadata that can be formatted, tested, linked etc.
You need a well defined spec like djot as a DSL for this to work, so that parsers can be easily written for it. This level of language support allows many different views onto the source code. We’re not there yet.
There’s no reason you couldn’t do something similar with markdown code blocks if someone were so inclined. But that’s tool dependent, not syntax.
I sort of agree with Karl’s point about there being too many standards of markdown, but I doubt org mode would have survived the same level of popularity without suffering the same fate.
It doesn’t help that there is no standard for org mode. You can only really use and take advantage of its power in emacs. It isn’t susceptible to lossy transformations because there’s only one real org mode editor.
But not all is well with Org Mode syntax either. Many git hosters have only a very rudimentary implementation of a parser and writing a parser for it is not actually that easy. Its dynamic nature requires at least a 2 step approach of parsing and then later checking all kinds of definitions at the top of a file and further processing the document according to that. It's power comes at that cost. That's probably why we have so many Markdowns, but only one Org Mode (OK maybe a few, counting Vim and VSCodium plugins, that achieve a feature subset).
I will say though, that org mode syntax is much better suited for writing technical documentation than markdown. The only issue is, that not so many people know it or want to learn it, and I don't know a way to change that. Perhaps that effort to have the org mode syntax separately defined (https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Over...) by the same author will help creating more support for the format in various tools.
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.
Is it though? Like for example, I often deal with Org-mode documents of several thousand lines of text and I honestly don't know any piece of software that can acceptably handle multi-thousand lines of markdown.
Emacs/Org-mode has tons of different ways to navigate and search through these large bodies - the outline nature of the structure is perfect for that - there's narrowing, collapsing/expanding, sparse-tree search, flexible sorting, indirect buffers, imenu, overlays and text properties that can render the text conditionally, etc.
I read HN and Reddit threads in Org-mode format¹; I browse my Jira board and tickets in Org-mode², I have Wiktionary lookup³ and Thesaurus⁴ - all in Org-mode.
¹ https://youtu.be/ud3Gmxg5UZg
² https://github.com/agzam/go-jira.el
³ https://github.com/agzam/wiktionary-bro.el
⁴ https://github.com/agzam/mw-thesaurus.el
Comparing Org-mode and Markdown and saying "Markdown is widely used [and thus it's better]" is wildly immature - popularity doesn't determine fitness for purpose - PHP is more widely used than Rust or Zig, but that doesn't make it "better" for systems programming.
I can agree, Markdown is adequate for relatively small documents like README files, but it's nowhere close to even try to compete with Org-mode in so many different aspects far beyond just the markdown format structure.
But be that as it may, if Markdown is inadequate for a variety of tasks, why do people use it for a variety of tasks? Your rebuttal is just “Here’s a task or two that I do that I think Org format is better for.” Fine. I don’t have an opinion about your tasks. I believe you that Org is better for those for you. But neither do those cases rebut the fact that MANY MORE people use Markdown quite successfully on a daily basis than Org for a wide variety of tasks (blogging, documentation, personal information management, etc.). Can Org also do those things? Yes, surely. Can Org do more than those things? Surely. But so can Markdown. So, if you want to say “Org format is better for ME and I can do more with it because it’s more feature full,” then I’d reply, “I’m sure you’re right.” But if you’re saying “Org is better for everyone,” well, then, the data just doesn’t support that.
And for the record I did not say that “Markdown is better.” You are putting words in my mouth. I said it was adequate for a wide variety of tasks. It works. It is sufficient. My proof for that is that it’s widely used for a variety of tasks. That’s it. Q.E.D.
You posted an opinion. Now, I'm very curious how you came to your conclusion: was is adequate? How to you compare?
Did you read the article and got the reasons mentioned why MD can be problematic?
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.