Broken org-persist-storage probably leads to ‘org-open-at-point’ ask for TAGS file

Broken org-persist-storage probably leads to ‘org-open-at-point’ ask for TAGS file

[Göktuğ Kayaalp]

Hello,

I have discovered a weird behaviour that I have tracked back to
org-persist and org-element-cache, where after some time, when I try to
follow a document internal link in org mode, whether to a headline or to
a =<<target>>=, it would ask me to load a TAGS file, I think somewhat
like how xref might ask you to do when you call say
‘xref-find-definitions’.

This has been going on for a few weeks I think and I finally had a
chance to debug this, and it appears that some problem in the persistent
cache might be triggering this bug. I haven’t been able to fully debug
the problem because by the time I had discovered it had anything to do
with org-persist and where the storage files for the latter were, I had
reset the database. I do not have a backup of ‘org-persist-directory’ to
compare thus, or, for now, to reproduce the bug.

It appears that one thing that can trigger the error is Org mode parser
errors. For example, while trying to poke around ‘org-open-at-point’ a
bit, I noticed that eval’ing the call to ‘org-element-lineage’ in its
definition

    (let* ((context
            ;; Only consider supported types, even if they are not the
            ;; closest one.
            (org-element-lineage
             (org-element-context)
             '(citation citation-reference clock comment comment-block
                        footnote-definition footnote-reference headline
                        inline-src-block inlinetask keyword link node-property
                        planning src-block timestamp)
             t))

resulted in the following warning, which then implored me to send a bug
report:

⛔ Warning (org-element-cache): org-element--cache: Org parser error in org.el.gz::333063. Resetting.
 The error was: (error "rx ‘**’ range error")
 Backtrace:
"  (backtrace-to-string nil)
  (org-element-at-point)
  (org-element-context)
  (org-element-lineage (org-element-context) '(citation citation-reference clock comment comment-block footnote-definition footnote-reference headline inline-src-block inlinetask keyword link node-property planning src-block timestamp) t)
  (progn (org-element-lineage (org-element-context) '(citation citation-reference clock comment comment-block footnote-definition footnote-reference headline inline-src-block inlinetask keyword link node-property planning src-block timestamp) t))
  (eval (progn (org-element-lineage (org-element-context) '(citation citation-reference clock comment comment-block footnote-definition footnote-reference headline inline-src-block inlinetask keyword link node-property planning src-block timestamp) t)) t)
  (elisp--eval-last-sexp nil)

after which the bug was triggered and I had become unable to use file
internal links in org mode.

In another instance an args out of range error in a ‘progn’ was
encountered while trying to store a link in a test buffer which only had
"\n\n\n<<link-here>>" in it, which again triggered the bug.

I then tried to disable the cache which didn’t help, and to reset the
cache and then some other things, listed below, which didn’t either. But
after restarting Emacs (with the org element cache enabled), I was no
longer able to reproduce the bug.

  (setf org-element-use-cache t)
  M-x org-element-cache-reset
  (org-element-cache-reset t t)
  (org-element-cache-refresh (point))
  (setq-local org-element--cache nil)
  (setq-local org-element--headline-cache nil)
  (setq-local org-element--cache-hash-left nil
              org-element--cache-hash-right nil)

It is after this point that I debugged further and discovered
org-persist and its role. Sadly the default location of
‘org-persist-directory’ is not a location I include in my backups, so I
cannot reproduce the bug unless I accidentally recreate whatever
triggered it.

All this debugging occurred in the org mode package as it comes with
upstream emacs, built by me from commit
6c4abbab7999f55792a323e4bb1eb55ef5a7b990. In case it is helpful, below
are links to my org mode config and Emacs build script

https://codeberg.org/cadadr/personal-computing/src/commit/748803bb63d756e0a2ec75b00c34dfbd1f40cf0f/emacs.d/gk/gk-org.el
https://codeberg.org/cadadr/personal-computing/src/commit/748803bb63d756e0a2ec75b00c34dfbd1f40cf0f/emacs.d/bin/build-emacs.sh

‘org-version’ reports

Org mode version 9.6.1 (release_9.6.1-34-geea8da @ /home/cadadr/local/emacs/share/emacs/30.0.50/lisp/org/)

The org-persist storage verion currently seems to be 3.1 (exceprt from
=/home/cadadr/.cache/org-persist/index= below). I don’t know what it was
beforehand, but I usually build Emacs from git tip every Sunday, so that
might give a tip

 (:container
  ((index "3.1"))

Sadly I cannot do any further debugging, as I can’t reproduce the bug
anymore.

    - Göktuğ.

P.S. Please keep me in CC if you want me to see your replies, I am not
subscribed to the list.

Re: Broken org-persist-storage probably leads to ‘org-open-at-point’ ask for TAGS file

[Ihor Radchenko]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> I have discovered a weird behaviour that I have tracked back to
> org-persist and org-element-cache, where after some time, when I try to
> follow a document internal link in org mode, whether to a headline or to
> a =<<target>>=, it would ask me to load a TAGS file, I think somewhat
> like how xref might ask you to do when you call say
> ‘xref-find-definitions’.
> ...

It appears to me that you had an issue with cache at some point, and then
it got propagated to disk, and triggered later on unrelated command.

May you set `org-element--cache-self-verify-frequency' to a larger value
and later let us know if you start seeing warnings from
org-element-cache?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>