Celorga vs Org Mode

The short version: if you want the best Org experience inside Emacs, use Org Mode. Celorga is for a different constraint: keeping much of Org's useful structure in ordinary files while using a native Mac app, VS Code, a standalone CLI, or other non-Emacs tools.

Celorga has two layers: the application, and the independently specified parser/runtime and semantic profile underneath it. Celorga is an independent project: it is not a fork, successor, or replacement for Org Mode, it is not affiliated with or endorsed by the GNU Org Mode project, and it does not claim complete Org compatibility. It implements a deliberately defined, portable interpretation of Org text.

At a glance

Question	Org Mode	Celorga
What is it?	A major mode and extensive toolset for GNU Emacs	A native workspace built on a standalone parser/runtime, CLI, and semantic profile
Natural home	Emacs	Celorga for Mac, VS Code, the CLI, and lightweight iOS workflows
Source files	`.org`	`.org`
Editing	Deep structural editing, folding, capture, refile, tables, and keyboard workflows	Native rendered/source views and a VS Code extension; less editing depth than Org Mode
Planning	Highly configurable TODOs, agendas, clocks, habits, repeaters, reports, and logs	Common TODO and planning semantics shared by the Mac app, VS Code, CLI, and agenda TUI
Tables and code	Spreadsheet-like tables and the mature Babel ecosystem	Safe `#+TBLFM:` evaluation, structured tables, preserved source blocks, SQL-backed data notes, and charts; not a Babel replacement
Publishing	Many built-in and third-party export backends and publishing projects	HTML/site publishing and Beamer-compatible presentation export
Automation	Emacs Lisp APIs and Emacs batch mode	Standalone commands, JSON output, LSP, MCP, and source-range-aware compiler output
Maturity	Decades of use, documentation, packages, and hard-won edge-case handling	Early alpha; useful today, but still changing

What carries over

The family resemblance is intentional. Celorga supports familiar outlines, TODO keywords, priorities, tags, scheduled and deadline timestamps, repeaters, property drawers, IDs, links, lists, tables, source blocks, clocks, habits, and agenda files.

The files remain the source of truth. There is no private note database that must be exported before another editor can read the work. Higher-level views are derived from the text.

That does not mean every Org file has identical behavior in both systems. The common syntax travels well; Emacs Lisp configuration and the long tail of Org semantics do not.

Where Org Mode is still far ahead

Editing and customization

Org Mode's editing model is the product of years of daily use: structural movement, folding, subtree operations, capture, refile, sparse trees, narrowing, table editing, links, and the agenda all fit together inside Emacs. Emacs Lisp makes the whole environment programmable.

Celorga does not reproduce that environment. Its Mac app is designed around files, agenda, meetings, search, data, and review. It includes rendered and source editing, but Org Mode remains the more powerful text editor. VS Code is currently Celorga's strongest general source-editing client.

Planning

Celorga covers the planning features needed by ordinary agendas: TODO state, schedules, deadlines, priorities, tags, effort, repeaters, habits, clocks, filters, and mutations. Org Mode goes much further. Custom agenda commands, logging rules, column views, clock reports, dependency rules, capture templates, and user-defined TODO workflows are substantially deeper and more configurable.

Tables, Babel, and export

Org tables can behave like a small spreadsheet, complete with formulas and a polished editor. Babel supports a large language ecosystem for literate programming and reproducible research. Org's exporter ships with several backends and has many more in packages.

Celorga parses tables and source blocks and evaluates a safe, useful subset of #+TBLFM: spreadsheet formulas across its CLI, rendered views, and exports. Its broader execution story remains narrower: explicit SQL/data blocks, materialized results, deterministic charts, HTML publishing, and presentation export. It does not execute Emacs Lisp formulas or replace Babel, so a serious Babel setup should stay in Org Mode.

Ecosystem and stability

Org Mode has a large community, a mature package ecosystem, and behavior that people have relied on for years. Celorga is an early-alpha project. Its format and core invariants are documented, but APIs and client UX are still evolving.

Why build Celorga at all?

Emacs already has batch mode and excellent APIs, so Celorga is not based on the idea that Org cannot be automated. The difference is packaging and scope.

Celorga makes a standalone, language-neutral runtime the default contract. A program can ask for an agenda, resolved links, diagnostics, search results, source ranges, or a published site without embedding Emacs or scraping an editor buffer. The Mac app, VS Code extension, scripts, and agents all consume that same runtime rather than inventing separate parsers.

That foundation lets Celorga provide a few things that are outside Org Mode's main job:

a native Mac workspace for files, agenda, meetings, data notes, and search,
an iOS companion for capture, agenda, file viewing, and approvals,
explicit local imports from configured sources such as Slack and Notion,
cited agent conversations and durable work records with outputs, validation, and approval steps,
preview-first command-line mutations that can be reviewed before they touch a file.

None of that requires AI. Parsing, agenda, links, graph checks, data materialization, linting, and publishing work without a model or API key.

Compatibility in practice

Existing .org files are normal Celorga compiler input.
Celorga creates documents as ordinary .org files, which open in org-mode without extra configuration.
Common headings, TODOs, planning lines, properties, tags, links, blocks, lists, tables, and timestamps should be unsurprising in either editor.
Celorga-specific declarations remain readable text in Emacs, but Emacs does not automatically give them Celorga behavior.
Custom Emacs Lisp, complex Babel graphs, specialized export backends, and heavily customized agenda rules do not port merely because the underlying file parses.
Celorga favors one coherent interpretation across its clients over bug-for-bug compatibility with every Org version and configuration.

The practical rule is simple: test a real corpus before depending on both runtimes for the same behavior. Keep advanced Org workflows in Org Mode unless Celorga explicitly documents support for them.

Should an Org user switch?

Not by default. If Org Mode already fits your editing and planning life, there is no reason to leave it.

Celorga is worth a look if you like Org's plain-text model but want:

a native application for day-to-day workspace use,
the same planning and link semantics available outside Emacs,
a standalone CLI for scripts, CI, or other editors,
local data and meeting workflows beside your notes,
review and approval machinery for work delegated to agents.

Using both is reasonable. Org Mode can remain the editor for .org files while Celorga supplies additional views and automation. Just treat the documented compatibility boundary as real rather than assuming that every Emacs customization has a portable equivalent.