2

In this manual page I read that idle time can be resolved both when one got distracted from the task at hand, and when the session unexpectedly crashed.

The latter is what happened to me (no hamsters involved, though), however I either do not understand the manual, or am doing something incorrect which I cannot spot.

I gather that, after a crash, still there is a line like this one in one's (possibly recovered) .org file:

*** <2022-01-10 Mon>
:LOGBOOK:
CLOCK: [2022-01-10 Mon 14:26]

However, there is no active clock really running, as if one tries C-c C-x C-o for org-clock-out, the minibuffer shows the warning about no clock being active.

I understood that C-c C-x C-z would scan the files in the org-agenda-files variable to look for hanging clocks, and then propose to ignore, add X minutes and so on, as one can read in the linked manual page. In my case, the options buffer does show up, however after choosing to ignore (i.e. keep the time) nothing happens to the clocked line, nor any info on the running clock appears in the info line.

Any suggestions as why this is happening?

2
  • Sounds like a bug to me. Please report it with M-x org submit-bug-report.
    – NickD
    Jan 12 at 9:51
  • Looking at org-clock-resolve, I think the i choice ends up setting the ch variable to nil, so it executes this branch in the cond: ((or (null ch) (not (memq ch '(?k ?K ?g ?G ?s ?S ?C ?t ?T)))) (message "")) which does nothing (other than clearing the echo area), just as you found. I'm pretty sure it's a bug.
    – NickD
    Jan 12 at 9:59

1 Answer 1

1

As explained in the comments, I'm pretty sure this is a bug. Here's a patch that might do what's needed (I don't really understand all the wrinkles in the code, so although it worked in the one test that I performed, it might fail spectacularly in other cases: you have been warned):

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index d44b5b7d7..7a2ef5af1 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -1129,6 +1129,7 @@ to be CLOCKED OUT."))))
       (org-clock-jump-to-current-clock clock))
      ((or (null ch)
           (not (memq ch '(?k ?K ?g ?G ?s ?S ?C ?t ?T))))
+      (org-clock-resolve-clock clock 'now last-valid t nil fail-quietly)
       (message ""))
      (t
       (org-clock-resolve-clock

Basically, in the case where ch is nil (IOW i or q was pressed - it shouldn't make any difference which), we do one additional thing: resolve the clock, giving it all the time up to now and make sure it's clocked out.

The diff is against Org mode version 9.5.2 (release_9.5.2-293-gb8656a) so it may not quite agree with the version you have and applying the patch might fail (and there may be whitespace problems too). But really all it is is adding one line, so assuming you can match the context, it should be pretty easy to patch it manually.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.