hckrnws

I hope org-mode gets more popular outside of Emacs. I know all the words already about how org-mode is great because of Emacs, but the way you can do plaintext outlining, with great support for TODO's, in org-mode is fantastic. It retains a lot of readability, and that isn't Emacs specific: there are things that make org-mode great as-is!

A small todo application for mobile that uses org-mode as the database doesn't need to parse fancy org-babel stuff, except maybe that org-mode itself can be hard to parse.

Personally I'm hopeful that org-mode gets some more love outside of Emacs, so here's a list of interesting org-mode projects that aren't pandoc or Emacs related:

- https://github.com/RWejlgaard/org - https://nvim-orgmode.github.io/ - https://github.com/haxscramper/haxorg - github.com/cnglen/windancer - https://braintool.org/

That won't change until top-notch, simple (i.e., without 100 transient dependencies) org parsing and formatting libraries for a few key languages (go, javascript / typescript, and python; maybe also C++ and java) become available.

Which is sad because org-mode seems far more versatile than markdown, except for a couple of ergonomic features (e.g., ``` vs #+BEGIN_SRC, and * [x] task vs * DONE task).

Even libraries to parse and format a subset of org-mode would be good enablers.

I think it gets away with being more verbose because those two aren't spelled "#+BEGIN_SRC" and "DONE", they're "C-c , q" and "C-c t d" (from memory). I think unless you really commit to learning a decent subset of what org-mode provides the ergonomics are always going to seem a little clumsy. I've always found emacs shortcuts hard to learn, and because of that I've never quite got my use of org-mode over the activation hump to really stick for the long term. Every time I leave it and come back to it I have to relearn a lot of it from scratch because there doesn't seem to be any sort of intuitive framework I can hang it all off.

I made my own macro* to encapsulate the currently selected text in SOURCE \END_SOURCE tags. Now you're telling me there was a keyboard shortcut for that?

What else I don't know about emacs?

*It was my first macro/function and while creating it I've learned that 1. It wasn't that hard and 2. With help of an LLM you can program emacs a little even without deep knowledge of elisp. Though LLMs suggest very unreadable elisp code and you have to rewrite everything.

The list of parsers is here: https://orgmode.org/worg/org-tools/index.html

There is orgzly on Android :

- https://github.com/orgzly-revived/orgzly-android-revived

But the fancy org-babel stuff is 90% of the reason I use org -- and that's only on Emacs as far as I know.

I sort of bounce off of org over and over because I find it very unreadable. Compared to Markdown (I know Markdown isn't quite the same thing), org feels very crusty and noisy.

This totally depends on how you set up your org face attributes. I keep using Org because, for me, it's far more readable than Markdown.

Also, it's always a tree. The three operations, like folding, traversal,. etc, are essential for me, and not available in Markdown.

Fortunately, GitHub understands README.org files.

Emacs folds and unfolds Markdown just like Org since about 29.0 at least I think.

While org mode can do almost anything, it is foremost an outliner, not a markup language like markdown. Using org-mode in place of Markdown is like using MS Word for coding, so no wonder

I think you are right. My real issue is that I don't have an "outliner" brain. I've never really understood why people make outlines or even, really, take notes.

Org's utility to me is then the making and keeping track of todos. But markdown can do that without much trouble.

I actually pandoced my Markdown files to Org mode a few years ago because Org mode is easier to read in plain text editors. I especially like the use of dashes for lists. However, even in Emacs Org mode, I still use `backtick` fences in inline code.

org-mode would need an Obsidian-level polished application to become a thing. This is not that simple, I guess...

BTW obsidian borrowed a few ideas from org-mode, like clickable checkboxes, creating ad-hoc daily notes, etc.

I don't know elisp, emacs keybindings, org-mode details, etc. But I have vibe-coded a note/task management system using it that's by far the best one I've ever used. It's very similar to Dynalist (but much more flexible). It has changed my life, honestly.

Even though I use emacs/org pretty much adversarily, it works almost flawlessly. Also looks pretty good imo [0].

I can capture notes/tasks to my inbox: by selecting text anywhere on my computer and pressing a keybind, by using a dialog provided by another keybind, from Quicknotes on iPhone, and from a webpage I have set up in case I'm using a computer/phone that's not mine.

I rsync my org files to a Dropbox, which allows me to access them on iPhone using beorg app.

Thanks emacs/org community! S2

0: https://ibb.co/7xW1NbRh

I was looking into org-mode after yet another system-collapse trying to manage everything in kanban (trello) + docs.

While it seemed like exactly what I needed, I was turned off by the TUI. So I kept looking and found something that, instead of running in a terminal, was effectively a Chrome browser, enabling all the "luxuries" of modern web apps while living on my local system.

Org-moders were definitely the OGs, but it's 2026 and the TUI novelty nostalgia, recently in full swing thanks to Claude Code, will wear off.

Terminal Emacs exists only so that experienced Emacs users can still get some approximation of their preferred setup when they're stuck unable to run the proper GUI version. I wouldn't pay too much attention to it.

TUIs are great for when you know your tools well. But yeah, it’s 2026 and we’ve never been less aware of the nuance in the tools we use.

Well I have absolutely no idea what worg is.

> The page you're reading is part of Worg, a section of the Org-mode web site that is written by a volunteer community of Org-mode fans: Worg sources are hosted here.

It includes tutorials, ideas, code snippets, etc., shared to make your introduction and customization of Org-mode as easy as possible. Worg is maintained by a group of Worg contributors, and maybe you.

The details are here [1]; the OP should probably add a clearer explanation.

[1] https://orgmode.org/worg/worg-about.html - Worg is a collaborative knowledge database about Org (Emacs org-mode).

How does that differ from the rest of orgmode.org? Is worg a wiki?

yup, it is basically a wiki

Yeah I had to CTRL-F Worg until I found the about link. Super confusing why they chose to link something else.

NGL, Worg is terrible at explaining what it does and what it is for. And this sentiment is coming from someone who uses Org mode daily and has contributed to Worg.

x

you wouldn't be the only one

Well despite the website being ambiguous about Worg until finding the about page, I support the project. I just hope it isn't as obtuse in its actualy tutorials.

We are Worg. Resistance is futile. You will be put into a tree structure, given completion statuses, timestamps, properties, and hyperlinks. Your formatting distinctiveness will be incorporated into our own.

So many good words, but they all miss the crucial point: you can't write a parser for org-mode. So elisp interpreted is needed to run the lisp code that defines it. It means that org-mode can be good while you are using it from emacs, and it sucks for anything else.

I use markdown now, because you have a lot of tools to deal with markdown, while all tools for org-mode are bound to emacs. Which is perfectly fits the emacs philosophy of emacs being an operating system, but it is not for me. It was fun 20 years ago, but now when I'm thinking of tinkering with emacs configuration for hours to get anything done, I feel an impulse to run away.

You can write a parser. In fact, there is a good number of parsers, including treesitter implementation. See https://orgmode.org/tools.html

If you need a new parser, the syntax specification is in https://orgmode.org/worg/org-syntax.html

There are incomplete parsers that cover most of the Org basics. For example, GitHub has one, crafted in Ruby. They use it to render e.g. readme.org files in repositories. It works quite well. I find the Org format very pleasant to work with.

I think the trick with Emacs and Org is to stick to the basics and then only add features or change your configuration very slowly, as needed. I have been using Emacs non-stop for >20 years and my .emacs is just 20 LOC. It's been shrinking, not growing. My goal is to bring it down towards 0 LOC. I have committed a few things upstream to modernize defaults.

Personally, I think the reputation of Org, Emacs, or Nix being hard and complex is undeserved. It's rather a documentation problem. There's no simple documentation to onboard newcomers and show them the basics in a principled way. So it looks like a mess, but it isn't.

> I have been using Emacs non-stop for >20 years and my .emacs is just 20 LOC. It's been shrinking, not growing.

Me too. I mean I'm using Emacs too, and it is 20+ years. I hate it deeply, and I cannot stop hating it because I cannot get away from it. I regret deeply choosing emacs 20+ years ago and spending 20 years to wrap my habits around it.

BTW my .emacs is still growing. I don't know how you manage to have 20 LoC of .emacs, I have a directory .emacs.d and a couple of dozen of files there. They are not large, some of them can be as small as 1 line. The last one I've wrote was dealing with indent of lua code. lua-ts-mode have some relatively simple rules that mostly work, but I was not happy with the result, there are some quirks that just are very inconvenient, and in some cases lua-ts-mode just fail to indent properly. So I fixed them to my taste. This one file is longer than 20 LoC.

Though, I should note, that LLMs make this much simpler. It is very simple to reverse-engineer what there is, and if you can explain the idea how to change the code, LLM can write all the elisp needed. It doesn't work out of the box, of course, and needs to be debugged, still LLM can save an hour or two.

> My goal is to bring it down towards 0 LOC.

You cannot. If you use lua you just cannot, because lua-mode uses indent of 3 spaces. Not 2, not 4, but three. So any lua sources you can find on github and try to edit will not be indented like lua-mode does. I cannot imagine what was going on the mind of the person who had chosen this value. The only possible explanation I have is something like "I want to be not like the others", but it doesn't seem right.

So you need at least to change lua-indent-offset (or lua-ts-indent-offset if you use treesitter), and it will be more than 0 LoC.

Thou shalt indent to three, no more, no less. Three shall be the number thou shalt indent, and the number of the indentation shall be three. Four shalt thou not indent, neither indent thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then compose thou thy Holy Lua.

:)

You could customize that variable instead, so that Emacs manages everything for you and you don't have to care that it would look like a line of code if you opened your settings and edited them directly.

Yes, there are some parsers around in languages other than elisp. This one seemed to work well when I tried it some time ago: https://github.com/rasendubi/uniorg

Care to share those 20 lines? Because I feel like every time I pick up a new language I need to add 5-10 lines to add some basic hooks and configs

This is incorrect. You can write a parser for org. See for example https://github.com/tgbugs/laundry. Work toward standardization has been stalled because I (among others) have not had time to circle back to work on it. In part this is because the lack of a standard has not blocked most use cases since emacs is open source and can run almost anywhere.

> You can write a parser for org. See for example https://github.com/tgbugs/laundry.

Oh, there are a lot of incomplete parsers. This one is not an exception:

> Status

> Laundry can parse most of Org syntax, though there are still issues with the correctness of the parse in a number of cases.

> In particular there are a number of edge cases in the interaction between the syntax for various Org objects that have not been resolved.

I have my own parser as a pest grammar. It has just the basic features. This Laundry seems to implement more of org-mode, but I don't care anymore really, because I believe that org-mode will not be reimplemented.

> In part this is because the lack of a standard has not blocked most use cases since emacs is open source and can run almost anywhere.

I have some inexplicable aversion to an idea starting elisp interpreter just because my program needs org-mode parser. But even if I could integrate elisp into my program as easy as I do with lua, I probably wouldn't do it, because parser in lisp doesn't really solves the problem, it simplifies it a bit (I don't need to deal with the grammar) but shifts to another level: I need to learn how org-mode is represented as a lisp object. I need to reverse engineer the formal definition of that recursive object to deal with it, or turn on defensive programming expecting anything.

The only realistic way of dealing with org mode is to write code for emacs. There are exceptions of this rule, like pandoc, but I don't trust them.

> Work toward standardization has been stalled because I (among others) have not had time to circle back to work on it.

I tried to not to react to this, but, I'm sorry, I'm too much of a troll to just leave it without commenting.

Of course you have no time to write a formal definition. No one has time for that, and no one will have time for this. Because at this stage it is practically impossible. The parser was written as a bunch of regexps intermixed with lisp code. All edge cases were baked into org-mode because those regexps are the definition of org-mode. To write a formal grammar you need to catch all those edge cases, and to reproduce the behavior of the existing parser.

In retrospect, the parser should've been replaced with a formal grammar definition at much earlier stage, when it was possible to replace parser with another one, which is similar but generally incompatible because it deals with edge cases in a different ways. When the time was missed those edge-cases became a legacy you cannot fix.

Why can't a parser be written? Is there a halting problem or a grammar conflict? Or is "can't" short-hand for "too much trouble"?

> Why can't a parser be written?

Because the existing parser is written in truly emacs style: no formal grammar, just a lisp code with a regexp at each turn. Theoretically speaking it doesn't forbid you from writing a parser, but in practice there are no full-blown parsers of org-mode except the reference one.

For many software businesses, licensing is an issue. The spec is GFDL with GPL code samples, a non-cleanroom translation of the elisp parser would (likely) be GPL (or at least arguably enough so to keep lawyers busy), so going and doing some other roughly equivalent markup language instead avoids the copyleft requirements.

So, yes, “too much trouble”, much of it nontechnical.

I also don't use org-mode anymore, but sometimes I really do miss org-babel-tangle. In contexts where doctests aren't available it can be really helpful for making sure code listings actually work.

the entire purpose of the website is lost to me. I had to figure it out by reading the comments.

How so? The second section, "Introduction to Org-Mode and Worg" explains it as well as one could possibly ask for. Are you really that completely thrown off by it being the second section rather than the first (admittedly a bad decision)?