[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#62300: closed (29.0.60; No hyperlinks for some symbols in *Help* buf

From: GNU bug Tracking System
Subject: bug#62300: closed (29.0.60; No hyperlinks for some symbols in *Help* buffers)
Date: Wed, 22 Mar 2023 15:53:02 +0000

Your message dated Wed, 22 Mar 2023 17:52:59 +0200
with message-id <83pm906aw4.fsf@gnu.org>
and subject line Re: bug#62300: 29.0.60; No hyperlinks for some symbols in 
*Help* buffers
has caused the debbugs.gnu.org bug report #62300,
regarding 29.0.60; No hyperlinks for some symbols in *Help* buffers
to be marked as done.

(If you believe you have received this mail in error, please contact

62300: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62300
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 29.0.60; No hyperlinks for some symbols in *Help* buffers Date: Mon, 20 Mar 2023 20:34:04 +0200
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
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:

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.

(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))

--- End Message ---
--- Begin Message --- Subject: Re: bug#62300: 29.0.60; No hyperlinks for some symbols in *Help* buffers Date: Wed, 22 Mar 2023 17:52:59 +0200
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 62300@debbugs.gnu.org
> Date: Tue, 21 Mar 2023 21:48:42 -0400
> > OK, master it is, then.
> Pushed,

Thanks, closing.

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]