unhammer / org-mru-clock Goto Github PK

even if it doesn't yet have a clock entry.
(Also have the same work in the agenda.)

That seems like a regular use case if you try to be more granular with your clock.

I prefer commands that DWIM. Unfortunately DWIM is very much a personal thing. :-)

Related package https://github.com/akirak/counsel-org-clock/ has a bunch of actions, presumably people find them useful?

If you do org-capture and file it, then there's a chance it's a task you'll work on soon.

Often I want to clock into a task which I'm not sure I've already created, that means I have to first attempt to clock in, and if it's not there then I have to cancel and capture the new task.

It would be great to be able to be able use the non-matching search as input to a pre-set capture template.

When doing org-mru-clock-in with point on a heading, that heading is included at the top of the list. But if the buffer is narrowed to that heading (org-narrow-to-subtree), we see the heading as its own parent, instead of the real parent.

If an item is SCHEDULED for today, but not yet clocked in to, it'd be nice if it were there in the org-mru-clock-in list, as a "suggestion".

• Should we mark it in some way?
• How far up the list should it be, if it's never been clocked in to?
• Should we include things that were scheduled in the past, but not clocked in to? How far back then?
• Will this make us much slower?

Using doom-emacs and creating the mru cache from org-agendas, whenever I trigger org-mru-clock-select-recent and select one of the default, interrupted, or current tasks I am sent to a different item in my org-journal folder (which is referenced at the bottom of my org-agenda-files).

It would be nice to be able to start a pomodoro timer in one of the recently clocked-in tasks. I believe org-pomodoro is the canonical package.

Thank you for your excellent work on this package.

(require 'org-mru-clocks) on line 46 should probably be (require 'org-mru-clock)

When I'm clocking in, it's unlikely that I want to clock into a task that's in a completed state. I started looking into refactoring to allow us to install a list of predicate filter functions, but figured I'd open an issue in case you've already looked at implementing something like this.

Debugger entered--Lisp error: (error "Bad bounding indices: 0, 43")
signal(error ("Bad bounding indices: 0, 43"))
error("%s" "Bad bounding indices: 0, 43")
cl-subseq((#<marker (moves after insertion) at 73765 in newgtd.org> #<marker (moves after insertion) at 61780 in newgtd.org> #<marker (moves after insertion) at 159358 in newgtd.org> #<marker (moves after insertion) at 160657 in newgtd.org> #<marker (moves after insertion) at 162969 in newgtd.org> #<marker (moves after insertion) at 163731 in newgtd.org> #<marker (moves after insertion) at 162235 in newgtd.org> #<marker (moves after insertion) at 399624 in notes.org> #<marker (moves after insertion) at 165481 in newgtd.org> #<marker (moves after insertion) at 165058 in newgtd.org> #<marker (moves after insertion) at 164459 in newgtd.org> #<marker (moves after insertion) at 57564 in newgtd.org> #<marker (moves after insertion) at 161814 in newgtd.org> #<marker (moves after insertion) at 29221 in idea.org> #<marker (moves after insertion) at 398942 in notes.org> #<marker (moves after insertion) at 108748 in newgtd.org> #<marker (moves after insertion) at 158915 in newgtd.org> #<marker (moves after insertion) at 398482 in notes.org> #<marker (moves after insertion) at 155868 in newgtd.org> #<marker (moves after insertion) at 147108 in newgtd.org>) 0 43)
org-mru-clock-select-workaround-history()
(let* ((org-clock-history (org-mru-clock-select-workaround-history)) (m (org-clock-select-task "Select recent task: "))) (if m (progn (switch-to-buffer (marker-buffer m)) (goto-char (marker-position m)) (org-up-element) (org-show-subtree))))
org-mru-clock-select-recent-task(nil)
funcall-interactively(org-mru-clock-select-recent-task nil)
#(org-mru-clock-select-recent-task nil nil)
apply(# org-mru-clock-select-recent-task (nil nil))
call-interactively@ido-cr+-record-current-command(# org-mru-clock-select-recent-task nil nil)
apply(call-interactively@ido-cr+-record-current-command # (org-mru-clock-select-recent-task nil nil))
call-interactively(org-mru-clock-select-recent-task nil nil)
command-execute(org-mru-clock-select-recent-task)

If using org-mru-clock-capture-if-no-match to capture new tasks, we don't want to stay clocked in if user did C-c C-k

If Emacs was killed with an open clock, then re-opened and you do org-mru-clock-in, you'll be asked whether to resume the clock or not. If you resumed, there's no point in showing the completion menu.

Similarly to unhammer/gnus-recent@6f13a00#diff-8c4133e8ab0f2f9dfa628bdbecfdaf0b3b74010f89649556f3d0a01e7b75954fR252-R263 we could predefine some actions. It's a bit of a drag though compared to ivy, since completing-read only gives us the car (string title) of the match, not the cdr containing the actual org-buffer marker (maybe worth an upstream bug report since others also want values, not just strings). So we have to re-lookup the cdr value in some map/alist.