unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: 62300@debbugs.gnu.org
Subject: bug#62300: 29.0.60; No hyperlinks for some symbols in *Help* buffers
Date: Mon, 20 Mar 2023 20:34:04 +0200	[thread overview]
Message-ID: <83y1nr6zmr.fsf@gnu.org> (raw)

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?

In GNU Emacs 29.0.60 (build 400, i686-pc-mingw32) of 2023-03-20 built on
 HOME-C4E4A596F7
Repository revision: 786de66ec3c4cff90cafd0f8a68f9bce027e9947
Repository branch: emacs-29
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils dabbrev
misearch multi-isearch pp cl-macs derived pcase subr-x help-fns
radix-tree cl-print byte-opt gv bytecomp byte-compile debug backtrace
help-mode find-func cl-loaddefs cl-lib rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 170820 17000)
 (symbols 48 7828 0)
 (strings 16 25056 2790)
 (string-bytes 1 712251)
 (vectors 16 12758)
 (vector-slots 8 191144 13690)
 (floats 8 36 30)
 (intervals 40 10017 117)
 (buffers 888 13))





             reply	other threads:[~2023-03-20 18:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-20 18:34 Eli Zaretskii [this message]
2023-03-20 18:52 ` bug#62300: 29.0.60; No hyperlinks for some symbols in *Help* buffers Eli Zaretskii
2023-03-20 21:55   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-21 13:11     ` Eli Zaretskii
2023-03-21 14:19       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-21 17:26         ` Eli Zaretskii
2023-03-21 17:59           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-21 18:23             ` Eli Zaretskii
2023-03-21 19:09               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-21 19:54                 ` Eli Zaretskii
2023-03-22  1:48                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-22 15:52                     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83y1nr6zmr.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=62300@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).