Tracking todo state changes AND automatically change to done when all children are done

Tracking todo state changes AND automatically change to done when all children are done

[Cletip Cletip]

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

Hello to all,

I am trying to do what is in the title of this mail, but there is something
surprising:

Everything works perfectly well, except when inserting statistics cookies
(for the parent obviously). Indeed, when changing the state of the subtask,
the lines like this :

- State " new state" from "old state" [2022-08-04 Thu 16:09]

are not saved under the subtask, but always under the main heading.

To reproduce this curious behavior, you only need this configuration:

  (setq org-todo-keywords
        '((sequence "TODO(t!)" "|" "DONE(d!)" )))

  (defun org-summary-todo (n-done n-not-done)
    "Switch entry to DONE when all subentries are done, to TODO otherwise."
    (let (org-log-done org-log-states) ; turn off logging
      (org-todo (if (= n-not-done 0) "DONE" "TODO"))))

  (add-hook 'org-after-todo-statistics-hook 'org-summary-todo)

;;(setq org-log-into-drawer t) ;;to have a logbook


and try on an org document like this one:


* TODO heading [0/1]

- State "DONE" from "TODO" [2022-08-04 Thu 16:09]

** TODO change the state of this heading !


My org-mode version is 9.5.2 (release_9.5.2-25-gaf6f12 @
/usr/share/emacs/28.1/lisp/org/).


Thank you in advance for your answers

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

Re: Tracking todo state changes AND automatically change to done when all children are done

[Ihor Radchenko]

Cletip Cletip <clement020302@gmail.com> writes:

> Hello to all,
>
> I am trying to do what is in the title of this mail, but there is something
> surprising:
>
> Everything works perfectly well, except when inserting statistics cookies
> (for the parent obviously). Indeed, when changing the state of the subtask,
> the lines like this :
>
> - State " new state" from "old state" [2022-08-04 Thu 16:09]
>
> are not saved under the subtask, but always under the main heading.

This is likely related to
https://orgmode.org/list/871qu8ccvr.fsf@localhost
CCing Bhavin.

> To reproduce this curious behavior, you only need this configuration:

Confirmed.

Something inside `org-todo' call in the hook triggers recursive-edit
that, in turn, triggers premature call to post-command-hook containing
note saving function.

Best,
Ihor

Re: Tracking todo state changes AND automatically change to done when all children are done

[Cletip Cletip]

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

So, can we consider this as a bug?

Le jeu. 4 août 2022 à 17:01, Ihor Radchenko <yantar92@gmail.com> a écrit :

> Cletip Cletip <clement020302@gmail.com> writes:
>
> > Hello to all,
> >
> > I am trying to do what is in the title of this mail, but there is
> something
> > surprising:
> >
> > Everything works perfectly well, except when inserting statistics cookies
> > (for the parent obviously). Indeed, when changing the state of the
> subtask,
> > the lines like this :
> >
> > - State " new state" from "old state" [2022-08-04 Thu 16:09]
> >
> > are not saved under the subtask, but always under the main heading.
>
> This is likely related to
> https://orgmode.org/list/871qu8ccvr.fsf@localhost
> CCing Bhavin.
>
> > To reproduce this curious behavior, you only need this configuration:
>
> Confirmed.
>
> Something inside `org-todo' call in the hook triggers recursive-edit
> that, in turn, triggers premature call to post-command-hook containing
> note saving function.
>
> Best,
> Ihor
>

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

Re: Tracking todo state changes AND automatically change to done when all children are done

[Ihor Radchenko]

Cletip Cletip <clement020302@gmail.com> writes:

> So, can we consider this as a bug?

Yup. And the linked thread may be the fix or at least something close.

Best,
Ihor

Re: Tracking todo state changes AND automatically change to done when all children are done

[Cletip Cletip]

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

Okay, I understand. Sorry for the duplicate, I didn't see this thread.

Also, I don't understand why, but when I click on it, no site is
accessible. I tried to remove the "@localhost", also nothing.
Do you know how to follow the thread ?

Thanks you again for your help.

On Fri, 5 Aug 2022, 03:26 Ihor Radchenko, <yantar92@gmail.com> wrote:

> Cletip Cletip <clement020302@gmail.com> writes:
>
> > So, can we consider this as a bug?
>
> Yup. And the linked thread may be the fix or at least something close.
>
> Best,
> Ihor
>
>

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

Re: Tracking todo state changes AND automatically change to done when all children are done

[Ihor Radchenko]

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

>
> Okay, I understand. Sorry for the duplicate, I didn't see this thread.


No problem. It's not like that thread is obviously related. I found the
relation in the root cause, after debugging.

Also, I don't understand why, but when I click on it, no site is
> accessible. I tried to remove the "@localhost", also nothing.
> Do you know how to follow the thread ?


Copy-paste the link manually? IDK. The link works on my side.
I guess you can search "org-auto-repeat-maybe: error "Can’t expand
minibuffer to full frame" and missing log note
<https://list.orgmode.org/orgmode/871qu8ccvr.fsf@localhost/#r>" subject in
https://list.orgmode.org/

On Fri, Aug 5, 2022 at 10:11 AM Cletip Cletip <clement020302@gmail.com>
wrote:

> Okay, I understand. Sorry for the duplicate, I didn't see this thread.
>
> Also, I don't understand why, but when I click on it, no site is
> accessible. I tried to remove the "@localhost", also nothing.
> Do you know how to follow the thread ?
>
> Thanks you again for your help.
>
> On Fri, 5 Aug 2022, 03:26 Ihor Radchenko, <yantar92@gmail.com> wrote:
>
>> Cletip Cletip <clement020302@gmail.com> writes:
>>
>> > So, can we consider this as a bug?
>>
>> Yup. And the linked thread may be the fix or at least something close.
>>
>> Best,
>> Ihor
>>
>>

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

Re: Tracking todo state changes AND automatically change to done when all children are done

[Cletip Cletip]

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

It's ok, I managed to find it, thanks

I realize that I also have the same mistake as him (Can’t expand minibuffer
to full frame).


I'm not good enough in emacs-lisp, but I hope it's not too complicated to
solve for you ^^.

Le ven. 5 août 2022 à 04:27, Ihor Radchenko <yantar92@gmail.com> a écrit :

> Okay, I understand. Sorry for the duplicate, I didn't see this thread.
>
>
> No problem. It's not like that thread is obviously related. I found the
> relation in the root cause, after debugging.
>
> Also, I don't understand why, but when I click on it, no site is
>> accessible. I tried to remove the "@localhost", also nothing.
>> Do you know how to follow the thread ?
>
>
> Copy-paste the link manually? IDK. The link works on my side.
> I guess you can search "org-auto-repeat-maybe: error "Can’t expand
> minibuffer to full frame" and missing log note
> <https://list.orgmode.org/orgmode/871qu8ccvr.fsf@localhost/#r>" subject
> in https://list.orgmode.org/
>
> On Fri, Aug 5, 2022 at 10:11 AM Cletip Cletip <clement020302@gmail.com>
> wrote:
>
>> Okay, I understand. Sorry for the duplicate, I didn't see this thread.
>>
>> Also, I don't understand why, but when I click on it, no site is
>> accessible. I tried to remove the "@localhost", also nothing.
>> Do you know how to follow the thread ?
>>
>> Thanks you again for your help.
>>
>> On Fri, 5 Aug 2022, 03:26 Ihor Radchenko, <yantar92@gmail.com> wrote:
>>
>>> Cletip Cletip <clement020302@gmail.com> writes:
>>>
>>> > So, can we consider this as a bug?
>>>
>>> Yup. And the linked thread may be the fix or at least something close.
>>>
>>> Best,
>>> Ihor
>>>
>>>

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

[BUG] Storing multiple log notes recursively only keeps the last note (was: Tracking todo state changes AND automatically change to done when all children are done)

[Ihor Radchenko]

Ihor Radchenko <yantar92@gmail.com> writes:

>> To reproduce this curious behavior, you only need this configuration:
>
> Confirmed.
>
> Something inside `org-todo' call in the hook triggers recursive-edit
> that, in turn, triggers premature call to post-command-hook containing
> note saving function.

I was wrong. Your bug has little to do with recursive edits.
It is related to the fact that log notes rely on global variables to
save the information about the note and record it in
`post-command-hook'.

What is happening is that `org-add-log-setup' is first called for the
child heading and then called for the parent heading in
`org-after-todo-statistics-hook'. The second call overwrites the global
note state.

Later, after Emacs finish executing the user command,
`org-store-log-note' is called, but it only sees the overwritten log
state - the one for the most recent call to `org-add-log-setup' (parent
heading). Thus only parent heading gets the actual note record.

We can solve the issue in multiple ways:
1. We may force recording the previous note (if any) at the beginning of
   `org-add-log-setup'.
2. We may alter `org-add-log-setup' to record the note using recursive
   edit. This way, every log note will be recorded immediately upon
   request.
3. We may maintain a log queue and record multiple logs one-by-one in
   post-command-hook.

I personally like option 2, but I am not sure about side effects.

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92