[HN Gopher] Org Mode Syntax Is One of the Most Reasonable Markup...
___________________________________________________________________
Org Mode Syntax Is One of the Most Reasonable Markup Languages to
Use for Text
Author : adityaathalye
Score : 219 points
Date : 2026-01-10 09:15 UTC (13 hours ago)
(HTM) web link (karl-voit.at)
(TXT) w3m dump (karl-voit.at)
| throw__away7391 wrote:
| We do not need another competing standard here. Markdown is
| adequate and more importantly widely adopted and growing.
| cenamus wrote:
| 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).
| rgoulter wrote:
| > 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).
| zelphirkalt wrote:
| > 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.
| fipar wrote:
| 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.
| alexisread wrote:
| 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.
| least wrote:
| 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.
| zelphirkalt wrote:
| 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/Ov
| er...) by the same author will help creating more support
| for the format in various tools.
| alexisread wrote:
| 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.
| throw__away7391 wrote:
| 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.
| binary132 wrote:
| 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.
| drob518 wrote:
| "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.
| iLemming wrote:
| > 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 format1; I browse
| my Jira board and tickets in Org-mode2, I have Wiktionary
| lookup3 and Thesaurus4 - all in Org-mode.
|
| 1 https://youtu.be/ud3Gmxg5UZg
|
| 2 https://github.com/agzam/go-jira.el
|
| 3 https://github.com/agzam/wiktionary-bro.el
|
| 4 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.
| drob518 wrote:
| 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.
| Spivak wrote:
| 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.
| rw_panic0_0 wrote:
| markdown
| noufalibrahim wrote:
| 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.
| jasperry wrote:
| 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!
| noufalibrahim wrote:
| 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_.
| karmakaze wrote:
| 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.
| maximus-decimus wrote:
| 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.
| rspoerri wrote:
| If org more was as successful as markdown it would likely also
| have a lot of unstandardized additions.
| zelphirkalt wrote:
| 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.
| tel wrote:
| 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.
| 1313ed01 wrote:
| 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).
| tel wrote:
| 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.
| hahajk wrote:
| 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.
| 1313ed01 wrote:
| 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.
| nanomonkey wrote:
| 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.
| xenodium wrote:
| 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.
| kleinishere wrote:
| 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.
| thetemp_ wrote:
| > 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.
| arboles wrote:
| 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\\*.
| 1313ed01 wrote:
| 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.
| arboles wrote:
| 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.
| skeledrew wrote:
| What's the use case for escaping its syntax? At top level it's
| just an arbitrarily nested list.
| imiric wrote:
| 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.
| arboles wrote:
| Karl Voit writes their articles in Org though, it even says
| so on the footer.
| skeledrew wrote:
| 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.
| arboles wrote:
| 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.
| org3 wrote:
| 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
| skeledrew wrote:
| 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.
| arboles wrote:
| The following: \~300 lines
|
| 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.
| skeledrew wrote:
| 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".
| arboles wrote:
| You didn't understand me. The highlighting also
| disappears if you "escape" with % %~300
|
| Or the character A: A~300
| fipar wrote:
| 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.
| skeledrew wrote:
| Have you tried literal examples?
|
| https://orgmode.org/manual/Literal-Examples.html
| fipar wrote:
| 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 :)
| adityaathalye wrote:
| 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
| arboles wrote:
| 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.
| jameshart wrote:
| 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.
| skeledrew wrote:
| 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.
| jameshart wrote:
| So like, ```org-mode * this is org
| ``` ?
| skeledrew wrote:
| 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.
| drob518 wrote:
| I'm not sure I see the benefit in that.
| skeledrew wrote:
| 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.
| jameshart wrote:
| 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.
| skeledrew wrote:
| 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.
| weslleyskah wrote:
| It's a matter of taste, isn't it? It's like LaTeX vs. Typst.
| You create the environment that works best for you.
| jameshart wrote:
| 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...?
| tikhonj wrote:
| 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).
| fipar wrote:
| 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.
| jameshart wrote:
| There are whole countries that drive on the left
| fipar wrote:
| 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.
| johanvts wrote:
| You cant even paste markdown into Slack, it's embarrassing.
| crazygringo wrote:
| 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.
| babarock wrote:
| 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?
| jameshart wrote:
| 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.
| crazygringo wrote:
| 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.
| adityaathalye wrote:
| 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.
| crazygringo wrote:
| 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.
| adityaathalye wrote:
| 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_T
| ESTS.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...
| tialaramex wrote:
| 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).
| wibbily wrote:
| 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...)
| drob518 wrote:
| 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.
| jrm4 wrote:
| 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. '"
| bitwize wrote:
| > This is advice that I would have rolled with pre-Generative
| AI.
|
| /me laughs in pandoc
| bitwize wrote:
| As long as we're telling people they should conform to what
| _everyone else_ uses, why aren 't you using Microsoft Word
| format instead?
| jameshart wrote:
| We are talking about _choosing a lightweight text markup
| language_. Not _choosing a file format for rich text files_.
| sorrythanks wrote:
| this is so true. i wrote a document in org and i'm still in the
| hospital after crashing into someone's markdown file
| noahjk wrote:
| 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!)
| vishnuharidas wrote:
| 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.
| Andrex wrote:
| And here I am still carrying the torch for BBCode-alikes...
| skeledrew wrote:
| 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.
| andai wrote:
| >some files going over 15MB in size
|
| Word count ~3 million? (~60 novels worth!)
| afroisalreadyin wrote:
| 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?
| skeledrew wrote:
| 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.
| stevekemp wrote:
| 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 | EUR1000", 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.
| stackghost wrote:
| 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.
| leobg wrote:
| 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.
| adityaathalye wrote:
| 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 :)
| __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 }
| skeledrew wrote:
| 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.
| exe34 wrote:
| 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.
| Groxx wrote:
| 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.
| toolslive wrote:
| 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.
| Groxx wrote:
| 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".
| toolslive wrote:
| 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.
| Groxx wrote:
| 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).
| toolslive wrote:
| 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.
| Groxx wrote:
| 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.
| jrm4 wrote:
| 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.
| tasuki wrote:
| Would you say the same about markdown?
| tasuki wrote:
| Ah. Well that sure shuts down the "you don't have to use Emacs"
| argument.
| Groxx wrote:
| 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.
| thetemp_ wrote:
| 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.
| Groxx wrote:
| 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/9q9m
| n6/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)
| jasperry wrote:
| Codeberg supports Org for READMEs! I think some other Git forge
| does too, but the name escapes me ;)
| arboles wrote:
| So does GitHub since forever BTW
| creata wrote:
| 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.)
| thetemp_ wrote:
| > 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.
| Spivak wrote:
| 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.
| thetemp_ wrote:
| 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.
| xenodium wrote:
| There's this https://orgmode.org/worg/org-syntax.html
| jackcviers3 wrote:
| 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.
| Groxx wrote:
| 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.
| jgoodhcg wrote:
| 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.
| d_sem wrote:
| 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.
| dannymi wrote:
| 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.
| durazabu wrote:
| What do you think about my orgmode obsidian plugin?
|
| https://github.com/BBazard/obsidian-orgmode-cm6
| dtkav wrote:
| Incredible work.
| d_sem wrote:
| very nice. Keep up the good work.
| diego898 wrote:
| 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
| phyzix5761 wrote:
| I added Evil Mode to my emacs and never went back to vim except
| for some quick edits in the terminal.
| getnormality wrote:
| 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.
| adityaathalye wrote:
| > 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.
| getnormality wrote:
| 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?
| dietr1ch wrote:
| 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).
| adityaathalye wrote:
| 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/s0z
| vlh/formal_specif...
| adityaathalye wrote:
| 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_ma
| r...
|
| 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.
| getnormality wrote:
| Maybe I'll try it someday! I'm always up for an
| underrated, high quality life improvement technology.
| dietr1ch wrote:
| 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.
| jauntywundrkind wrote:
| 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...
| beej71 wrote:
| 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
| erichocean wrote:
| 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.
| creata wrote:
| > 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?
| beej71 wrote:
| 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!
| beej71 wrote:
| 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.
| jenadine wrote:
| 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.
| itmitica wrote:
| Question: why is `https://orgmode.org/` in html and not in ...
| org mode?
| creata wrote:
| 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.
| itmitica wrote:
| Yeah, but still not org mode.
| IshKebab wrote:
| 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?
| dandersch wrote:
| > 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.
| vga42 wrote:
| >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.
| IshKebab wrote:
| > 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.
| indymike wrote:
| 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.
| tconfrey wrote:
| 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...
| 827a wrote:
| The only reason why Org mode doesn't have twenty variants like
| Markdown is because no one uses it.
| Derbasti wrote:
| 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.
| stackghost wrote:
| >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.
| WhatIsDukkha wrote:
| 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.
| stackghost wrote:
| 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.
| adityaathalye wrote:
| 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:
| #+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
|
| 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.
| G3rn0ti wrote:
| 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.
| cyrialize wrote:
| 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
| tconfrey wrote:
| 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...
| cyrialize wrote:
| 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.
| kleinishere wrote:
| 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.
| cyrialize wrote:
| 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.
| cyrialize wrote:
| 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.
| cyrialize wrote:
| 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.
| otikik wrote:
| It would get more adoption if it wasn't tied to the waist to
| emacs.
|
| Markdown doesn't require Vim.
| justinhj wrote:
| 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.
| justinhj wrote:
| 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.
| dctoedt wrote:
| [delayed]
___________________________________________________________________
(page generated 2026-01-10 23:00 UTC)