The four differences between .org and CommonMark I could spot right now is that the latter lacks metadata[0], macros[1], syntax for specifying language for inline code blocks[2], and for tables[3].

It's hard to separate .org the markup language from org-mode the application, because quite a lot of its syntax is driven by application features. TODO markers, time stamps, schedule/deadline markers, property drawers, log books, tags - all of these are part of Org Mode functionality, but have little use if you're just trying to write a document for export.

--

[0] - There's ton of stuff you could optionally add with #+SOMETHING: lines - local configuration of how to work with the file, metadata, exporter settings for any format individually and all of them together, and more. A lot of those can also be specified per-headline.

[1] - https://orgmode.org/manual/Macro-replacement.html; crazy, but when it's needed, it works wonders.

[2] - You can make Markdown-style code spans in Org Mode ~like this~, but there's actually a syntax for proper inline source code blocks that's much less known: src_lang{code}, or src_lang[header-args]{code}. For example, src_lisp{(+ 2 2)} or src_lisp[:results output]{(format t "Foobar")}. The reason for the header-args variant is that Org Mode inline code blocks can be executed interactively or on export, just like regular code blocks. See: https://orgmode.org/manual/Structure-of-code-blocks.html for details on both.

[3] - In CommonMark you could technically abuse HTML for that, but Org Mode provides the most readable format for tables... that's also the most convenient to write if you're using Org Mode, and an absolute PITA if you're not. See: https://orgmode.org/manual/Tables.html.

Going off of table support:

- org mode is at least as powerful as excel thanks to gnu cal or straight up lisp

- org mode tables are nuts in the sense that you can refer to cells from your text (paragraphs, titles etc). Its neat because it means that when writting a report, you can refer to results of computations in tables - meaning that you can then change constants in the table and numbers will update in you document body (paragraphs etc)

Ive tried explaining org mode with as little words as possible to people and it goes like this:

- its as simple as markdown (a subset of orgmode is isomorphic to md)

- its as powerful as jupyter notebooks (although you can have a cell in scala refering to the output of a python cell itself taking as inpute the output of a previous bash cell)

- its as powerful as excel and word, but you can refer to table cells into your document (copy paste excel table in word, refer to table cell from word body, change excel and see changes appear in word paragraphs refering to said cells)

- its as poweful as pandoc (my spacemacs exports org files to latex, html, odt, md, etc in 5 keys)

- its a fantastic todo manager (drop todos in documents instead of going to todo app and refer todo to org file) although you git for multi user todos.

- its got macros (so you can make macros that will inject html/tex code at export so you can have arbitrarily complex pdfs (html+princexml+css or just latex). If anyone’s interested, i can write an article about this paricular feature. Ive automated my reports to have double page bg images and other goodies but (macro)-enhancing org)

- its got a UI (aka shortcuts) to easily add tables, rows, lines, realign tables etc. So text tables end up being more productive than word/excel tables (although they’re a pain to git since git will version table “indents” instead of cell content since a line can change but not its semantic content)

- its infinitely hackable (make a gantt program in js and make an org cell that takes some DSL code and outputs gantt. It already exists for uml, flowcharts (in emacs you have artist mode, so text flowcharts are eazzy) etc)

I thinks thats about all it is, but i’ve surely forgot about feature im unaware about because i havent needed them yet.

Org mode surely reminds me of apple UIs which ive always described as “your grandma can use it, yet your avg power user will find his spot”. Org is as easy as Md if that’s what you want, but also as powerful as you need it to be if thats what you want.

Thanks for org mode and emacs, its taught me about the sort of things you can make a computer do. And ive only been an emacsian (?) for 2 years, but as a 27 year old (emacs still conquering youngsters ?), ive finally found what i needed to be productive, and hot damn have i not been these past to years (thanks to org, magit, ace, dired, tramp, flycheck, term, evil (im a vim guy originally), helm, which-key, undo tree, the elisp api, paredit, the many others im forgetting, and of course spacemacs). And originally i switched to emacs to have a better window control, lol. Thanks to vs code (which btw is a fantastic editor) which didnt have what i needed (i could switch from a pane to the tree with a shortcut but i had to click to escape the tree (but with helm no trees needed anymore, fiouf), ive discovered life :)

But yeah, org mode is insanely powerful, give it a try. If i were to think of org mode’s power and flexibility as a text editor, its be emacs ;p (or is it the opposite?)

Cheers,

A GNU fanboy

One feature I didn't see in your list is the ability to mix any LaTeX code into the org document, enabling to get all features of LaTeX but a far more compact and simple syntax for the common cases. This is the main reason I switched from Markdown: I now can use a single file format for every kind of document, without any limitations.

I've written an entire XP planning tool in Org mode. Unfortunately I don't know where it is any more (it was a long time ago). I should dig it up.

The biggest issue I’ve had with org tables is that, in certain situations, you just can’t have particular characters in an org table and have the advanced features work.

I guess these days it is better to compare GitHub Formatted Markdown, a common extension to CommonMark, as opposed to plain CommonMark. It supports code blocks with language hints, tables etc. Also, I am pretty sure Markdown with metadata (sometimes referred to as "front matter") already exists and is called MultiMarkdown, though presumably not as powerful/useful as what you describe here.

> code blocks with language hints

CommonMark also supports code blocks with language hints (using the ```lang... syntax). What Org-mode has, in addition to code blocks with language hints, is inline code with language hints, which neither CommonMark nor GFM support.

> tables

I'm horrified that, indeed, CommonMark doesn't have tables, though you're right that most people now just use GFM.

Org offers much more functionality than MD. Tags, TODOs with start dates and deadlines, an agenda view, capture templates, and a jupyter like notebook format with org-babel that allows for selectively integrating live code snippets into org documents.

Been using it for >2 years now and for sure only using a fraction of its capacity.

The big difference between Markdown and the Org-markup is that the latter has syntax for various kinds of metadata, while Markdown is purely content. That metadata is used for things like task management, literate programming, spreadsheets, customizing export behavior, etc.

One could, in theory, create an extended Markdown flavor that allows similar metadata, but that wouldn't be compatible with any existing tools anyway, so there's not much point.

Pretty sure Markdown with metadata (sometimes referred to as "front matter") already exists and is called MultiMarkdown, no?

By "various kinds of metadata", I don't just mean the document metadata (such as title, author, etc.), but also the metadata applied to specific elements such as the outline items, tables or code blocks.

For example, in Org you can add task management data, scheduling information and arbitrary properties to the outline,

    #+COLUMNS: %ITEM %TODO %ASSIGNED_TO %SCHEDULED %PRIORITY
    #+PROPERTY: ASSIGNED_TO_ALL juki some other people

    * TODO [#A] Some task with priority A
    SCHEDULED: <2019-04-20>
    :PROPERTIES:
    :ASSIGNED_TO: juki
    :END:

    Some description.

This defines a task with a custom property `ASSIGNED_TO` whose value can be one of ["juki", "some", "other", "people"], which can be viewed and edited in a column view. It could also be used by a custom export-backend or some other tool.

For another example, you can add formulas to a table,

    #+CAPTION: A table with formulas.
    | foo | bar | Row sum |
    |-----+-----+---------|
    |  10 |  20 |      30 |
    |  30 |  40 |      70 |
    |-----+-----+---------|
    |  40 |  60 |     100 |
    #+TBLFM: $3=vsum($1..$2)::@4=vsum(@I..@II)

Here the 10, 20, 30, 40 are added manually and the other cells are calculated by the sum-formulas. Since the results are inserted into the table, other tools can just skip over the TBLFM-metadata if they don't support it.

So they way I see it, `org` file format and `org-mode` are 2 different things.

On surface level, `org` files don't bring carry many significant advantages over similar formats like Markdown; rather, it's Emacs's `org-mode` that brings this text file to life.

You can have a full-fledged calendar and scheduling system just in a few lines of text. Imagine that.

Org is just a shorthand as far as I know. Emacs Org-Mode works with files typically ending in ".org". I prefer to avoid the confusion by saying "Org-Mode" and "Org-Mode files" fully (and, I believe, properly).

I think not having to balance headline length with underline length is a good plus. Also not having to memorise the hierarchy of underline characters is a good plus.

The format seems better suited to extension too with ways to have annotations or blocks

You can do headings in Markdown like org mode, just use # instead of *:

  # Level 1
  ## Level 2
  ### Level 3
  #### Level 4
  etc.

I rarely see the fiddly format in the wild, probably for the reasons you mentioned, and because it only allows H1 and H2:

  Level 1
  =======
  
  Level 2
  -------

Of course there are lots of things org mode does better than Markdown, I'm just addressing the specific point you mentioned.