bug#62300: 29.0.60; No hyperlinks for some symbols in *Help* buffers

[Eli Zaretskii]

> Date: Mon, 20 Mar 2023 20:34:04 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> To reproduce:
> 
>   emacs -Q
>   C-h f global-text-scale-adjust RET
> 
> Observe that in the *Help* buffer the variable
> global-text-scale-adjust-resizes-frames does not have the link
> appearance.  This is because:
> 
>   (boundp 'global-text-scale-adjust-resizes-frames) => nil
> 
> By contrast, if you try
> 
>   C-h f text-scale-adjust RET
> 
> then the variable text-scale-mode-step in the *Help* buffer does get
> the link appearance, and boundp returns non-nil for that variable.
> 
> The reason seems to be that in the latter case typing the "C-h f"
> command causes face-remap.el to be loaded, whereas in the former case
> face-remap.el is not loaded.  I traced that to a problem which can be
> demonstrated by the following recipe:
> 
>   emacs -Q
>   M-x load-library RET help-fns RET
> 
> Now evaluate:
> 
>  (radix-tree-prefixes (help-definition-prefixes) "global-text-scale-adjust")
> 
> This returns nil, whereas if you do the same with "text-scale-adjust",
> you get:
> 
>   (("text-scale-" "face-remap") ("tex" "flyspell"))
> 
> Interestingly, just appending a dash to global-text-scale-adjust, i.e.
> 
>  (radix-tree-prefixes (help-definition-prefixes) "global-text-scale-adjust-")
> 
> does yield non-nil result:
> 
>   (("global-text-scale-adjust-" "face-remap"))
> 
> The non-nil result causes help-fns.el:help--symbol-completion-table to
> load the file:
> 
>     (when help-enable-completion-autoload
>       (let ((prefixes (radix-tree-prefixes (help-definition-prefixes) 
> string)))
>         (help--load-prefixes prefixes)))
> 
> The load happens inside help--load-prefixes.  As result face-remap.el
> is loaded for text-scale-adjust, and the variables defined in
> face-remap.el become defined.  With global-text-scale-adjust the
> loading doesn't happen, and the variable stays unbound.
> 
> This sounds like some snafu with some heuristic somewhere, perhaps in
> radix-tree-prefixes, or in the code which registers the prefixes to
> begin with?
> 
> Can this be fixed, please, so that variables referenced in doc strings
> would reliably be displayed as links?

Adding Stefan.

Stefan, any suggestions or ideas?