Re: Question about todo subheadings and logbook

[Keith M Swartz <oneroadkms@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]

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:
#+SEQ_TODO: TODO(!) PEND(!) DONE(!)

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?

Thanks,
Keith


On Fri, Sep 4, 2015 at 11:52 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Keith M Swartz <oneroadkms@gmail.com> 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.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>



-- 

Keith M Swartz
oneroadkms@gmail.com

[-- Attachment #2: Type: text/html, Size: 4335 bytes --]