Hello, Michaël Cadilhac <mich...@cadilhac.name> writes:
> CONTEXT: When I'm idling with the clock running, Org asks if I want > to resolve the clock when I come back (this is by setting > org-clock-idle-time). > > PROBLEM: I'm not sure how recent the change was, but Org started > asking me _multiple times_ what I want to do when back. Could you provide an ECM? > CAUSE: It seems that the mechanism that prevents multiple such > questions is broken. It boils down to checking whether > org-clock-resolving-clocks is non-nil in org-resolve-clocks-if-idle. > The problem is that org-resolve-clocks-if-idle then calls > org-clock-resolve, which does *not* change org-clock-resolving-clocks > (that's the job of org-resolve-clocks, it seems). > > POSSIBLE SOLUTION: (if we agree there is a problem) Check for > org-clock-resolving-clocks-due-to-idleness rather than > org-clock-resolving-clocks in org-resolve-clocks-if-idle. How does > that sound? I don't know well this part of the code base. A cursory look at commit abfc6babcaf6e20a4c12e5c4754ce107ddc0dc7b didn't help much. Maybe `org-resolve-clocks-if-idle' could check for `org-clock-resolving-clocks-due-to-idleness' /in addition/ to `org-clock-resolving-clocks'. > Maybe org-clock-resolve should also set > org-clock-resolving-clocks; is there a use case where > org-clock-resolve may be called multiple times (with timers probably) > with different clocks, and we'd want all of them to prompt the user? I don't understand. `org-clock-resolving-clocks' is meant to prevent calling low-level function `org-clock-resolve' unnecessarily. I don't see a need for setting it also in `org-clock-resolve'. Regards, -- Nicolas Goaziou