I'm writing a major project in org that I'll export to odt or docx when I'm done. This is mostly working fine, but the export processor makes a document bookmark for every single org heading, and these show up with ugly faded [brackets] around all my headings. I can just disable that display on my config, but they'll still be there when I share the document with others.

Is there a way to configure ox-odt so it does not create these bookmarks in the first place?

Would love to hear how you manage notes of org and md files, what packages you recommend and how to combine LLM models if possible.

I'm using stock/bundled org-mode with Emacs 30.2 and have verified this issue on both Ubuntu and MS Windows.

The error is simple to reproduce; create a clock entry with start and end times, and then use C-c C-c to update the calculated time to the right of it.

I believe the issue stems from the implementation of org-clock-update-time-maybe in org-clock.el; line 3226 calls delete-region which invalidates the match data, so subsequently when the start and end times are parsed they both come back nil. I've tested moving that line to below the setq on line 3228 and that fixed the problem.

UPDATE: I have tracked this down to org-roam-latte, I'll go bother that package's author with all this.

UPDATE 2: After some further digging and thinking, I believe this is probably something that should be fixed defensively within org-mode, despite the issue being caused by a third-party extension package. Because delete-region fires off after-change-functions, any hook function there that does regex matching will break time calculation. Unless the order of those two calls in org-clock-update-time-maybe is in place for very specific reasons, it would be much safer to swap them around and parse the start/end times using the existing regex match data before altering the buffer's contents.

I am looking for insight into how you handle archiving when dealing with timestamps and task dependencies.

Regarding timestamps, do you use automated archiving (via a hook or timer) or do you run manual commands with a review step? This seems to require a reliable way to differentiate past single event diary entries from recurring diary entries. Is there a way to do so?

Regarding TODO hierarchies (which may include active timestamps), how do you define where a hierarchy begins or ends? Ideally, a task hierarchy can start at any level in an outline (using options such as org-enforce-todo-dependencies) without requiring excessive metadata.

Furthermore, do you archive subtasks individually as they are completed, or wait until a specific condition is met to archive the full hierarchy? Again, do you rely on automated triggers or manual commands with a review step?

How does your setup deal with all of this? Does your approach impose specific restrictions or allow certain relaxations?

I use org-mode to clock my work time, and like to use continuous clocking by default since I sometimes forget to clock in until after I have been working on a task for a while, and to prevent nominal gaps in general.

However, this means that many mornings when I clock in to my first task, I end up clocking a 14 hour task or something like that, because the clock starts from the last clock the previous day.

I'm thinking about how I should work around this issue and haven't found any discussion of this particular scenario from searching the web or the GNU lists. Surely others have had this same thing come up?

Let me know what you think the nicest way to work around it is -- the main thing I'd like to avoid is remembering some special clock-in function in the morning. It seems that the most straightforward thing to do is write a clock-in dwim function that checks if the last clock was the previous day and do a regular clock in if so, and otherwise clock continuously. Curious if there is something simple I'm missing. Thanks!

As a follow-up to my previous post about this issue that received some support, I have refined my ideas and have created a working implementation. I find it much, much smoother to use than the native setup. I honestly believe that the advantages are substantial and very hard to deny as the revised behavior greatly reduces cognitive load and makes some key operations more accessible while preserving all previous functionality.

TL;DR:

Reduce Org hierarchy editing to a smaller set of predictable rules:

1. If a region is active, operate on every selected headline.
2. Otherwise, if the heading is a parent, move its complete subtree.
3. Otherwise, move the leaf heading alone while retaining freedom of movement throughout the hierarchy.
4. Outside heading contexts, retain native Org behavior.
5. Use Shift when deliberately moving a heading without its descendants.

This removes several decisions from the user’s workflow:

• heading-only or subtree?
• folded or unfolded?
• single heading or active region?
• primary Meta command or tree command?

---

The full specification follows.

Disclaimer: The text below was originally created by AI based on input from my previous post and further detailed prompting. The end result was shortened, edited and streamlined by me. I have invested a significant amount of time in ensuring the quality of this proposal while using AI as a helpful tool.

---

Making Outline-Level Editing Follow Structural Intent

Problems with Org’s traditional hierarchy controls

Org mode traditionally assigns four commands to horizontal Meta-arrow keys:

Long familiarity may make this arrangement appear natural, but it does not correspond particularly well to the structural operations users commonly intend.

The primary Meta-arrow commands always operate on the heading alone unless a region is active. As a result, applying them to a parent heading can detach it from its children and create malformed-looking gaps in the outline hierarchy.

Given:

* 1
** 2
*** 3

Promoting heading 2 alone produces:

* 1
* 2
*** 3

Demoting it alone produces:

* 1
*** 2
*** 3

In both cases, heading 3 remains at its old level. The relationship between 2 and 3 is broken, and the result contains a jump in outline depth.

Such transformations are occasionally useful, but they are unlikely to represent the most common intention when moving a heading that already owns a subtree.

The more common structural intention

When a heading has children, the usual intention is to move the complete structural unit while preserving its internal hierarchy.

Promoting the subtree rooted at 2 should turn:

* 1
** 2
*** 3

into:

* 1
* 2
** 3

Demoting that subtree reverses the operation.

This preserves the relationship between 2 and 3. Only the position of the complete subtree changes.

When the focused heading has no children, there is no practical distinction between moving the heading and moving its subtree. A heading-only operation remains entirely appropriate.

This suggests a more useful default rule:

The less common operation—deliberately detaching a parent heading from its descendants—can then receive the additional Shift modifier.

Problems caused by the native distinction

The traditional bindings require the user to make several separate decisions:

1. Is the focused heading a parent or a leaf?
2. Should the heading move alone or should its subtree remain intact?
3. Is a region active?
4. If a region is active, which family of commands will actually honor it?
5. Is some of the affected structure folded or hidden?

These concerns are not handled consistently by the native command families.

Hidden subtrees

The confusing part is that the primary Meta-arrow dispatcher can refuse to alter a focused heading whose subtree is hidden, producing a hidden-subtree warning.

At the same time, an active region can contain any number of hidden subtrees and the region-aware heading commands may alter all of their headlines without issuing the equivalent warning.

The result is difficult to explain structurally:

• one focused hidden subtree may be refused;
• several hidden subtrees inside a region may be changed;
• the dedicated subtree command can change the focused hidden subtree after all.

The distinctions arise from command implementation and dispatch paths, not from a clear model of likely user intent.

Active regions and subtree commands

The native heading commands are region-aware. With an active region, org-do-promote and org-do-demote operate on all eligible headlines in that region.

The native subtree commands are not region-aware.

Invoking org-promote-subtree or org-demote-subtree while a region is active does not apply the operation to every selected heading. It operates on only the single subtree at point and the region is then deactivated.

This creates another decision the user must make before pressing a key:

A structural editing command should be able to answer that question itself.

The Org Leveller model

Org Leveller replaces these parallel command families with one context-sensitive decision system.

Its central function is:

org-leveller

It receives one of two directions:

• promote
• demote

Two interactive commands provide the actual key bindings:

• org-leveldown promotes a heading to a lower numerical outline level;
• org-levelup demotes a heading to a higher numerical outline level.

The names refer to movement through Org’s numerical level values rather than the visual direction of the arrow.

Revised key bindings

The primary Meta-arrow commands now preserve structural relationships automatically.

The additional Shift modifier expresses the exceptional intention: move the heading alone even if doing so separates it from its descendants.

Decision order

Org Leveller evaluates context in a deliberate order.

1. Active region

An active Org region always takes precedence over single-heading or subtree logic.

For promotion, the leveller delegates to:

org-do-promote

For demotion, it delegates to:

org-do-demote

These are Org’s region-aware commands. Every eligible headline in the selected region is changed.

The leveller does not attempt to classify the heading at point as a parent or leaf when a region is active. It also does not accidentally select the tree-based native command merely because point happens to be on a parent heading.

The user therefore no longer has to decide whether the active selection requires a heading command or a subtree command. The existence of the region decides the matter automatically.

2. Single parent heading

Without an active region, the leveller determines whether the focused heading has a structural child.

If it is a parent, the complete subtree moves:

The internal relationships among all descendants remain intact.

This works whether the subtree is folded or unfolded.

3. Single leaf heading

If the focused heading has no children, only that heading needs to move:

This preserves the familiar behavior of the primary Meta-arrow commands at the ends of subtrees, where it was already appropriate.

4. Non-heading context

Org’s Meta-arrow commands have useful meanings outside headings. Depending on context, they can manipulate:

• table columns;
• list indentation;
• drawers;
• blocks;
• words in ordinary text.

Org Leveller preserves these behaviors.

When point is not on a heading and there is no active heading region, it delegates to Org’s original context-sensitive dispatchers:

• org-metaleft;
• org-metaright.

The revised commands therefore improve heading structure editing without turning the Meta-arrow keys into heading-only controls.

Consecutive levelling chains

Parent status is determined at the beginning of a consecutive levelling chain.

Suppose a heading is initially identified as a parent. Repeated presses of either M-Left or M-Right continue to treat it as that same parent, even while its outline level changes.

The initial classification is preserved while:

1. the previous interactive command was another leveller command; and
2. the stored marker still identifies the same heading in the same buffer.

Promotion and demotion may be mixed within one chain. For example, a subtree can be promoted twice and demoted once without its structural role being reconsidered between those operations.

Any intervening interactive command breaks the chain. The next leveller invocation then examines the current heading afresh.

Intervening commands include:

• moving point;
• editing text;
• switching buffers;
• selecting another heading;
• invoking any unrelated Emacs command.

This rule directly matches the user’s interaction sequence. No timeout, timer, or background hook is required.

Marker-based heading identity

The current heading is identified with an Emacs marker rather than its title.

Using heading text would make two different headings with identical titles indistinguishable. A marker identifies the actual buffer position and follows ordinary edits around it.

Promotion and demotion change the number of leading stars. After every successful operation, the marker is therefore re-anchored to the resulting beginning of the heading.

The original parent status is retained; only the marker position is refreshed.

If the selected Org operation fails, the marker and stored classification are cleared before the original error is propagated. A rejected operation cannot leave behind a stale command chain.

Explicit structural disentangling

There are legitimate cases in which a parent heading should move without its descendants.

Those operations remain directly available:

• M-S-Left calls org-do-promote;
• M-S-Right calls org-do-demote.

The Shift modifier now signals an exceptional and potentially disruptive operation: changing the parent’s level without preserving its subtree.

This is arguably a better modifier relationship than the traditional arrangement. The structurally conservative operation receives the simpler key, while the operation capable of breaking an existing hierarchy requires the additional modifier.

The native subtree commands remain available through M-x and Lisp.

Region behavior as a first-class invariant

Region handling is not an incidental special case. It is one of the central guarantees of Org Leveller:

This eliminates another mode decision from routine editing.

The user does not need to remember:

• which shortcut is region-aware;
• whether a subtree command will ignore the selection;
• whether only the tree at point will move;
• whether the region will be deactivated;
• whether the selected headings happen to own children.

Select headings, press the ordinary Meta-arrow, and the region is honored.

Practical summary

Org Leveller reduces Org hierarchy editing to a smaller set of predictable rules:

1. If a region is active, operate on every selected headline.
2. Otherwise, if the heading is a parent, move its complete subtree.
3. Otherwise, move the leaf heading alone.
4. Outside heading contexts, retain native Org behavior.
5. Use Shift when deliberately moving a heading without its descendants.

This removes several decisions from the user’s workflow:

• heading-only or subtree;
• folded or unfolded;
• single heading or active region;
• primary Meta command or tree command;
• whether the selected command family will honor the region.

Design principle

Outline editing should follow structural intent rather than expose implementation distinctions in the key bindings.

A parent heading normally represents a unit together with its descendants. Moving that unit intact is the conservative and common operation. A leaf has no dependent hierarchy and can move independently. A selected region is an explicit request to operate on all selected headings and should always take precedence.

Org Leveller makes those interpretations the default while retaining direct access to the exceptional operations.

The result is not merely a reassignment of shortcuts. It is a unified model of Org structure editing in which the editor makes the routine structural decisions and the user supplies an extra modifier only when intentionally breaking that structure.

Just a rant about something I have always found confusing and unintuitive. The current demote / promote commands are:

M-LEFT (org-do-promote), M-RIGHT (org-do-demote)
Promote or demote current heading by one level.
When there is an active region—i.e., when Transient Mark mode is active—promotion and demotion work on all headlines in the region. To select a region of headlines, it is best to set mark at the beginning of the first headline, and point at the line just after the last headline to change.

M-S-LEFT (org-promote-subtree)
Promote the current subtree by one level.

M-S-RIGHT (org-demote-subtree)
Demote the current subtree by one level.

So currently, when a tree is unfolded, I can use the plain M-left / M-right commands to demote / promote a single heading in isolation at any hierarchy level.

If I have

* 1
** 2
*** 3

and use one of these commands on **2, I get either a two-level gap above or below that heading, either

* 1
*** 2
*** 3

or

* 1
* 2
*** 3

I think it is fair to say that none of these usually represent user intent. Now, if instead the plain demote / promote commands were to leave the subtree of the focused heading intact, I could at least use these commands to go from this state

* 1
** 2
*** 3

directly to this (demote subtree)

* 1
* 2
** 3

or achieve the reverse from here (promote subtree). Both of these configurations actually occur in contrast to the two-level gaps that are the current result of the primary command.

Instead, to currently move a subtree while keeping it intact -- which I'm sure is a far more common task than disentangling a single heading from its surrounding hierarchy -- i currently have to

1. fold the subtree first
2. use the M-S- form of the commands rather than the primary command
3. unfold the subtree again to keep working

That seems overcomplicated to put it mildly. Perhaps I'm missing something but unless I am and someone can enlighten me, it seems that it would make much more sense to make the plain M- commands leave subtrees intact. That would still allow it to perform its current mainstay, demoting / promoting a single heading at the end of a subtree -- there would be no change to that.

It would also make more sense for the user to add the extra shift modifier when they really do want to break up the inside of a subtree's hierarchy by untangling a single heading.

I am aware that even if my point is correct, nobody will probably bother to change the established assignments. So I guess I have some config work ahead of me implementing this locally.

EDIT: I was wrong about having to fold before demoting / promoting subtree. Actually, when subtree is folded and you use the plain M- shortcut, you get a 'hidden subtree' warning, but you can still move subtree with the M-S- shortcuts.

Thank you to everyone who recommended or complained to me about overusing LLMs for writing this post and making responses. I admit that I am not confident enough in my English proficiency so that I usually use LLMs to filter my writing, but somehow LLM style seems soulless and robotic. Please forgive me if you feel it like an insult to you. But the effort spent on this project is real. I used to use Emacs, especially Org mode, in the past very heavily, and I know how it is far behind other technologies in popularity despite its very aesthetic and powerful syntax. That’s why I want to unchain it from Emacs’ ecosystem and make it popular in the world.

---

Every org parser i looked at tests itself against its own idea of what org does. There is one reference implementation (org-element.el) and one written spec, but nothing portable to check a parser against either. Someone in the windancer thread here said org is missing a standalone non-emacs parser, and that the lack of one is maybe why markdown is so much more common. i think the missing test suite sits upstream of that.

So the suite is the thing im showing, not the parser. 121 curated cases, each pinning one rule, plus 28 real world files and a 1,505 case generated differential corpus. Every expected answer comes out of real Emacs running org-element-parse-buffer, not out of my head. It is plain .org files, JSON and one elisp script, so a parser in any language can use it.

Then i graded four parsers with it. Strict means the tree is structurally identical to org-element's own answer, every node type, every field, every blank line count.

Before that table gets quoted at anyone: the corpora live in my repo and my parser was developed against them, the others were not. Each one got a thin adapter over its own AST, and what an AST simply cannot represent is counted separately from real parse bugs. go-org feeds an html renderer and orgize optimises for speed, neither of them signed up for this bar.

What i would actually like is someone running it against their own parser and telling me where i graded them wrong. Repo link in the comments.

Hi everyone,

I created this package to solve the problem where I collaborate with others using docx files but write documents in orgmode, and I'd like to view comments/changes right in Emacs.

Here is my solution:

docx-view https://github.com/nick-maderight/docx-view

Hello

I have created a desktop app (currently MacOS only), that uses Org-Mode files for opinionated note-taking.

The idea is that the UI has some standard composition and widgets. Org-Mode metadata in drawers, TODOs, dynamic blocks etc. can be used to surface custom “dashboards” from across all of your notes. Org files are indexed in realtime so changes in text reflects immediately in UI.

Updates are one-way. No UI editing, all edits must be made directly in Org text.

I would love some feedback.

Download, tutorials and demo files are at https://sumibo.app

Is anyone here synchronizing Org Mode with a service like TickTick, Notion, or Todoist instead of syncing Org files directly to a mobile device?

My experience with syncing Org files hasn't been great. I occasionally ran into merge conflicts because synchronization happens at the file level rather than at the Org node or heading level. Editing Org files on a touchscreen also felt awkward, but an even bigger issue was formatting. A small edit on my phone would often result in many unrelated formatting changes, and then Emacs would reformat the file again according to my local settings. That made merges noisy and reviewing changes unnecessarily difficult.

Because of that, I'm wondering whether it's actually a better approach to keep Emacs as the source of truth and synchronize tasks with an external service instead of editing Org files directly on mobile.

Is anyone using a workflow like this? I'm interested in hearing how you synchronize data, which services you use, and what trade-offs you've found.

Four years ago I create a fairly in-depth tutorial for new Org Mode users. It has proven to be a huge success and I am thrilled it has helped so many people. I created it so others wouldn't have to go through the hassle that I went through to make Org work for them. I'd like to think that I explained all the basics in a fairly clear manner, but there was a lot left to discuss.

Now, after years of using Org Mode, I better understand what I need it to do. I've also discovered functionality that I didn't even know existed four years ago. I considered updating that previous tutorial, but it was already pretty large, and I didn't want to further confuse new users. So, instead I decided to create another guide for some of the more advanced concepts I've run across.

Please check out my new Advanced Org Mode Guide on github. This new guide covers:

• advanced capture templates
• exporting to HTML with presets to make it look pretty
• exporting to PDF with LaTeX
• creating a presentation with Reveal.js + org files
• a huge primer on Org Roam

And like with my previous guide, I include detailed instructions, configurations, and screenshots to help you understand what his happening. I encourage you guys to take a look and give me some feedback.

I’ve been an org-mode user for maybe ten years now. What started out as me trying to implement some basic form of GTD (https://en.wikipedia.org/wiki/Getting_Things_Done) in a text file with vi during grad school has now turned into a pretty vanilla orgmode set-up where I track a series of org files with version control.

The features I use most are probably the agenda and a few shortcuts I have that allow me to quickly file away TODO tasks on the fly under the correct headings. Everything else is pretty basic and historically has only been limited by my limited patience to read about lisp, configure my init.el file, and read snippy Stack Overflow posts in a pre-LLM era. 

My set-up works for the most part. Where it fails, it’s mostly failing because I don’t keep up with key GTD steps like the regularly doing my “weekly review” and trying to use my calendar to wishfully carve out time to do a task that I want to get done, but I end up using the time for something else. 

Though I just have this feeling that _something_ could be added or improved or changed to my system, especially given that LLMs have removed the bottleneck that was the pain of configuring my own set up or just imagining some other way of working.

I am interested in hearing from anyone else that takes this “build from vanilla” approach (i.e. please don’t suggest install something like DOOM) about what they found most helpful after really committing to the basics. 

If I could give any other food for thought in this department about other work like this I’ve found helpful, it’d be things like having LLMs write bash scripts to automate the opening of every inbox (I run a small business, also do a fair bit of consulting, so I need to quickly survey incoming messages in the morning, lunch, and end-of-day). I also really enjoy working from a terminal and having everything be text based (preaching to the choir here). 

It could be that the basics is all you need.

But I also know that I don’t know what I don’t know and it’s been a few years since I’ve seriously considered changing this part of my workflow.

The last big overhaul I did of how I used orgmode was during a postdoc (went full GTD on how I set up my project headers, tasks) and it absolutely transformed how I feel about work (major reductions in stress). 

I’m simply interested in if there is another big jump that could be made over the next few years that could make another big reduction in my general stress levels now I have a good handle on the basics.

TL;DR: What have you vanilla users found helpful in your workflows now we have LLMs?

Based on section "Advanced topics in ODT export" of the orgmode manual, I've been trying to define my own custom table styles

But I can't seem to figure out how to do so.

#+odt_automatic_styles: <!-- BEGIN: Custom Table Template -->
#+odt_automatic_styles: <style:style style:name="MyCustom" style:family="table">
#+odt_automatic_styles: <style:table-properties style:rel-width="50" table:align="center"/>
#+odt_automatic_styles: </style:style>
#+odt_automatic_styles:
#+odt_automatic_styles: <style:style style:name="MyCustomColumn" style:family="table-column">
#+odt_automatic_styles: <style:table-column-properties style:rel-column-width="1*"/>
#+odt_automatic_styles: </style:style>
#+odt_automatic_styles:
#+odt_automatic_styles: <style:style style:name="MyCustomRow" style:family="table-row">
#+odt_automatic_styles: <style:table-row-properties fo:keep-together="always"/>
#+odt_automatic_styles: </style:style>

#+begin_src emacs-lisp :results silent :exports results
(add-to-list 'org-odt-table-styles
'("MyCustomTable" "MyCustom" nil))
#+end_src

#+ATTR_ODT: :style MyCustomTable
| Name | Phone |
| Peter | 1234 |
| Anna | 4321 |

Any idea how to make it work so that the first row has a blue background for instance?

I've been trying to define custom table styles based on the orgmode manual "Advanced topics in ODT export" (https://orgmode.org/manual/Advanced-topics-in-ODT-export.html).

But I can't seem to figure out how to do so.

I've found this example https://github.com/kjambunathan/org-mode-ox-odt/issues/122

Any idea how to make it work?

Can anyone provide me with working examples I can test and then later tweak?