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.