Re: [O] Bug: ‘(org-resolve-clocks)’ picks the wrong target for placing a new clock-drawer when ‘org-clock-out-remove-zero-time-clocks’ is set to t [9.1.14 (9.1.14-9-g131531-elpa @ ~/.emacs.d/elpa/org-20181126/)]

[Nicolas Goaziou]

Hello,

Leo Vivier <address@hidden> writes:

> Hello,
>
> There seems to be a bad interaction between ‘(org-resolve-clocks)’ and
> ‘org-clock-out-remove-zero-time-clocks’ set to t. Whilst the right
> tree is targeted by ‘(org-resolve-clocks)’ to delete the clock-line
> and clock-drawer, it adds a new clock-drawer in the next tree rather
> than on the one being acted on.
>
> I was able to replicate this problem with ‘emacs -Q’.
>
>
> DESCRIPTION:
>
>
> I use org-clock regularly, and recently re-discovered
> ‘org-clock-out-remove-zero-time-clocks’. When I forget to clock an
> item, I run the following commands in quick succession:
> # ------------------
> (org-clock-in)
> (org-resolve-clocks)
> <INPUT>: g 10 <ENTER> (For indicating that I ‘got back’ 10 min ago)
> # ------------------
>
>
> Because those commands are run in quick succession, the time between
> ‘(org-clock-in)’ and ‘(org-resolve-clocks)’ is usually equal to 0 min.
> Therefore, when ‘(org-resolve-clocks)’ calls ‘(org-clock-out)’ after
> pressing <ENTER>, the clock-line is deleted, and if the clock-drawer
> was created by ‘(org-clock-in)’, it also gets deleted.
>
>
> The problem occurs in this context (‘|’ represents ‘(point)’):
> # ------------------
> * Subtree 1
> ** Item|
> * Subtree 2
> # ------------------
> ‘Item’ is the subtree we want to clock in the past. ‘Subtrees 1 & 2’
> are regular subtrees without any newlines separating them (the
> white-space is important).
> Please note that I was only able to get ‘(org-resolve-clocks)’ to
> trigger in an agenda-file with already had clocking info. I recommend
> that you try the snippet in one of your own agenda-files rather than
> trying it in a blank buffer.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou