Re: org-ctags land grab

[Nick Dokos]

Ihor Radchenko <yantar92@posteo.net> writes:

> Nick Dokos <ndokos@gmail.com> writes:
>
>> `org-ctags' unilaterally sets the hook `org-open-link-functions' to a
>> bunch of org-ctags functions and enables itself by default. That has
>> the unfortunate consequence of invalidating the documentation for
>> internal CUSTOM_ID links - see
>>
>> https://emacs.stackexchange.com/questions/76351/how-to-follow-an-internal-link-in-recent-org-mode
>
> As documented in the top comment of org-ctags.el, the default behaviour
> of C-c C-o is modified as you observe:
>
>     ;; By default, with org-ctags loaded, org will first try and visit the tag
>     ;; with the same name as the link; then, if unsuccessful, ask the user if
>     ;; he/she wants to rebuild the 'TAGS' database and try again; then ask if
>     ;; the user wishes to append 'tag' as a new toplevel heading at the end of
>     ;; the buffer; and finally, defer to org's default behavior which is to
>     ;; search the entire text of the current buffer for 'tag'.
>
>> I proposed a work-around, but it seems to me that `org-ctags'
>> functionality should be opt-in and there should be a way to turn it
>> off.
>
> It is off by default.

It is off until org-ctags is loaded. *When* it is loaded, it runs
`(org-ctags-enable)' and the behavior changes.

Now I'm not loading it explicitly, but nevertheless, *somebody* does
because it goes ahead and mucks with my `org-open-link-functions'.
One clue was that it does not happen in 28.2 (which is the version
in Fedora 36 and 37) but it *does* happen in a 30.0.50 Emacs built
from upstream sources.

So I ran some tests, all with -Q so my init file is out of the
picture.

It turns out that it is enough to ask for help on an Org variable to
have `org-ctags' loaded!  I put a watch on `org-open-link-functions'
and did `C-h v org-latex-pdf-process': it stopped once on setting it to
nil and it stopped again with this backtrace (I elided long lines but I left
the relevant portion of the one that mentions `org-ctags'):



--8<---------------cut here---------------start------------->8---
Debugger entered--setting org-open-link-functions to (org-ctags-find-tag): 
  debug--implement-debug-watch(org-open-link-functions (org-ctags-find-tag) set 
nil)
  set-default(org-open-link-functions (org-ctags-find-tag))
  add-hook(org-open-link-functions org-ctags-find-tag t)
  org-ctags-enable()
  byte-code("\300 \210\301\302!\207" [org-ctags-enable provide org-ctags] 2)
  load("org-ctags" noerror nomessage)
  help--load-prefixes((("org-" "ox-latex" "ox" "org-src" "org-refile" 
"org-protocol" "org-plot" "org-pcomplete" "org-mouse" "org-macs" "org-list" 
"org-keys" "org-habit" "org-faces" "org-ctags" ...
  help--symbol-completion-table("org-latex-pdf-process" ...
  test-completion("org-latex-pdf-process" help--symbol-completion-table ...
  completion--complete-and-exit(20 41 exit-minibuffer ...
  completion-complete-and-exit(20 41 exit-minibuffer)
  minibuffer-complete-and-exit()
  funcall-interactively(minibuffer-complete-and-exit)
  call-interactively(minibuffer-complete-and-exit nil nil)
  command-execute(minibuffer-complete-and-exit)
  read-from-minibuffer("Describe variable: " nil ...
  completing-read-default("Describe variable: " help--symbol-completion-table 
...
  completing-read("Describe variable: " help--symbol-completion-table ...
  byte-code(...
  call-interactively(describe-variable nil nil)
  command-execute(describe-variable)
--8<---------------cut here---------------end--------------->8---

As you see, `help--load-prefixes' loads `org-ctags'. If you look at
the `help-definition-prefixes' radix tree, `org-ctags' is subsumed
under the `org-' prefix, so any lookup with that prefix will end up
loading it (and therefore enabling it). The reason it does not happen
in 28.2 is that it is only under the `org-ctags` prefix.

It seems to me that `org-ctags' should be registered under the
`org-ctags' prefix only, just like in 28.2 (the registration is in
`org-loaddefs.el' but I don't know how it ends up there. I guess
`org-fixup.el' is doing it, but I didn't chase it any further).

I also think that loading `org-ctags' should not automatically enable
it: it should require the user to explicitly run `org-ctags-enable' to
do that. That way, if there is a mechanism that loads it
surreptitiously, it wouldn't cause the confusion that it causes
now. That would require documentation changes, but it would avoid
unpleasant surprises, and preserve some toes even if users load it
accidentally. Eventually, it might be nice to provide a disabling
function as well, although the workaround in the SE post works well
enough for now. Maybe the thing to do is to turn it into a proper
minor mode.

Thoughts?

-- 
Nick