org-node-cache-mode ends with:
(org-mem-reset)
(org-mem-tip-if-empty)
org-mem-reset starts an asynchronous scan, and org-mem-tip-if-empty is then
asked whether the cache is empty — which, on a cold start, it always is at that
instant. So enabling the mode reliably prints a warning about a scan that goes
on to succeed.
org-node-cache-ensure does not have this problem: it awaits first, then tips.
MWE
emacs -Q --batch, with org-mem and org-node on load-path:
(require 'org-mem)
(require 'org-node)
;; A directory holding one file with one ID.
(setq org-mem-watch-dirs '("/tmp/orgmemmwe/"))
(message "--- enabling modes ---")
(org-mem-updater-mode)
(org-node-cache-mode)
(message "--- awaiting scan ---")
(org-mem-await "" 30)
(message "after scan: %d files, %d id-nodes"
(length (org-mem-all-files)) (length (org-mem-all-id-nodes)))
Output:
--- enabling modes ---
org-mem: No files found in ‘org-mem-watch-dirs’, and no org-ids because Org not loaded
--- awaiting scan ---
after scan: 1 files, 1 id-nodes
How visible it is
It depends on whether org-mem's scan has landed by the time org-node-cache-mode
runs. With the two use-package blocks from the manual, whatever else init does
in between often covers the gap. I defer both to a single hook (Doom's
doom-first-input-hook), so they load back to back and the message appears every
session — over ~430 files the scan takes about 2 s.
Suggested fix
Ask the question where it can be answered — from
org-mem-post-full-scan-functions, one-shot — so the tip reports a cache that is
still empty after the scan meant to fill it. Locally I do:
(defun my-tip-when-settled (&rest _)
(remove-hook 'org-mem-post-full-scan-functions #'my-tip-when-settled)
(org-mem-tip-if-empty))
(cl-letf (((symbol-function 'org-mem-tip-if-empty) #'ignore))
(org-node-cache-mode))
(add-hook 'org-mem-post-full-scan-functions #'my-tip-when-settled)
which keeps the diagnostic for a genuinely empty cache and drops the false alarm.
Versions: org-node 10ea878, org-mem 07094da, Emacs 30.2.
Investigated with Claude Code; the MWE output above is from a real run.
org-node-cache-modeends with:org-mem-resetstarts an asynchronous scan, andorg-mem-tip-if-emptyis thenasked whether the cache is empty — which, on a cold start, it always is at that
instant. So enabling the mode reliably prints a warning about a scan that goes
on to succeed.
org-node-cache-ensuredoes not have this problem: it awaits first, then tips.MWE
emacs -Q --batch, with org-mem and org-node onload-path:Output:
How visible it is
It depends on whether org-mem's scan has landed by the time
org-node-cache-moderuns. With the two
use-packageblocks from the manual, whatever else init doesin between often covers the gap. I defer both to a single hook (Doom's
doom-first-input-hook), so they load back to back and the message appears everysession — over ~430 files the scan takes about 2 s.
Suggested fix
Ask the question where it can be answered — from
org-mem-post-full-scan-functions, one-shot — so the tip reports a cache that isstill empty after the scan meant to fill it. Locally I do:
which keeps the diagnostic for a genuinely empty cache and drops the false alarm.
Versions: org-node 10ea878, org-mem 07094da, Emacs 30.2.
Investigated with Claude Code; the MWE output above is from a real run.