From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith M Swartz Subject: Re: Question about todo subheadings and logbook Date: Fri, 4 Sep 2015 12:22:16 -0700 Message-ID: References: <87k2s6koeg.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c33e6e7a607f051ef0d29d Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49876) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXwZK-0001I8-An for Emacs-orgmode@gnu.org; Fri, 04 Sep 2015 15:22:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXwZJ-0006xs-1a for Emacs-orgmode@gnu.org; Fri, 04 Sep 2015 15:22:38 -0400 Received: from mail-lb0-x235.google.com ([2a00:1450:4010:c04::235]:36189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXwZI-0006wN-LS for Emacs-orgmode@gnu.org; Fri, 04 Sep 2015 15:22:36 -0400 Received: by lbcao8 with SMTP id ao8so16494179lbc.3 for ; Fri, 04 Sep 2015 12:22:35 -0700 (PDT) In-Reply-To: <87k2s6koeg.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Keith M Swartz , Emacs-orgmode@gnu.org --001a11c33e6e7a607f051ef0d29d Content-Type: text/plain; charset=UTF-8 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 wrote: > Hello, > > Keith M Swartz 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 --001a11c33e6e7a607f051ef0d29d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 cre= ate sub-level todos, and change their state, the updates all get muddled, a= nd you can't tell which one's state changed. It also creates multip= le 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(!)
<= br>1. Create an item, make it a todo. (Creates a logbook.)
<= br>2. Create a subheading. (Alt-Enter, shift-right) Make it a todo. (This a= dds 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 sta= te changed.)

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

4, Go back to the main heading and c= ycle the state to PEND. (This creates ANOTHER logbook right underneath the = heading showing the state change. The original record for when it was marke= d 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 t= he older entry is for the main heading, but if states keep going back and f= orth, you'll lose track quickly.)

This can't be a desi= red 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 wa= nts 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-item= s.

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 th= is, I think the easiest fix is to define org-metareturn-hook to call org-cy= cle (to collapse the drawer) and org-end-of-line (so it's positioned af= ter where the drawer would be) BEFORE invoking org-metareturn to add the su= bheading. 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 no= de.

Any thoughts on this approach as a solution to my iss= ue?

Thanks,
Keith

<= /div>

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= 9;ll hit
> Alt-Enter to do this. When I do, it creates the subheading /between/ t= he
> original todo and the drawer. Is that correct?

It is.

> My preference - and what I would have assumed to be the correct behavi= or -
> 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



--
--001a11c33e6e7a607f051ef0d29d--