[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Question about todo subheadings and logbook

From: Keith M Swartz
Subject: Re: [O] Question about todo subheadings and logbook
Date: Fri, 4 Sep 2015 12:22:16 -0700

Thank you, Nicolas.

I think this behavior is wrong, then, or else I have some configuration setting that's messing things up. Problem is, if you create sub-level todos, and change their state, the updates all get muddled, and you can't tell which one's state changed. It also creates multiple logbooks if you go back and change the state of the main heading at some point. (I also can't help but wonder if this is partly due to changes in org-mode 8.3 regarding property drawer syntax.)

Here is an example to reproduce some questionable results:

0. Create a set of TODO labels, like so:

1. Create an item, make it a todo. (Creates a logbook.)

2. Create a subheading. (Alt-Enter, shift-right) Make it a todo. (This adds a line to the logbook saying the state changed to TODO, even though the previous line says the state already is TODO. You can't tell which state changed.)

3. Cycle the state on your sub-todo to PEND. (Changes the state in the logbook.)

4, Go back to the main heading and cycle the state to PEND. (This creates ANOTHER logbook right underneath the heading showing the state change. The original record for when it was marked TODO is in the other logbook, but there are two such entries, and it's not obvious which one is which. You could probably infer logically that the older entry is for the main heading, but if states keep going back and forth, you'll lose track quickly.)

This can't be a desired behavior for anyone -- you either want multiple logbooks for each item and subitem, OR you want a single logbook the whole time. And if someone wants the latter, I don't see how it can be at all useful if you can't tell whether the main item's state was changed or one of the sub-items.

I could debate whether this is a bug, but my emacs is nothing if not versatile, so bug or not, I'm fairly confident there's a way to get the behavior I DO want. To that end, I was hoping somebody could offer a suggestion.

However, the more I dive into this, I think the easiest fix is to define org-metareturn-hook to call org-cycle (to collapse the drawer) and org-end-of-line (so it's positioned after where the drawer would be) BEFORE invoking org-metareturn to add the subheading. Actually, I'd probably want something more specific than org-cycle, since I don't want it to expand the drawer or some other tree node.

Any thoughts on this approach as a solution to my issue?


On Fri, Sep 4, 2015 at 11:52 AM, Nicolas Goaziou <address@hidden> wrote:

Keith M Swartz <address@hidden> writes:

> I often want to add a subheading (sub-task) to this todo item, so I'll hit
> Alt-Enter to do this. When I do, it creates the subheading /between/ the
> original todo and the drawer. Is that correct?

It is.

> My preference - and what I would have assumed to be the correct behavior -
> would be to have the subheadings appear /after/ the logbook drawer, as each
> subtask can also have a todo state and its own logbook.

The logbook drawer can be anywhere in the entry. So creating headline
after the drawer is fuzzy. Also, it is to smart. What if I want to
create a new headline that would use this logbook?

Sometimes, the simpler is the better.


Nicolas Goaziou


Keith M Swartz

reply via email to

[Prev in Thread] Current Thread [Next in Thread]