From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#62300: 29.0.60; No hyperlinks for some symbols in *Help* buffers Date: Mon, 20 Mar 2023 17:55:40 -0400 Message-ID: References: <83y1nr6zmr.fsf@gnu.org> <83ttyf6ys3.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4942"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 62300@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 20 22:57:00 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1peNUw-00011s-T9 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Mar 2023 22:56:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1peNU6-0005ds-5f; Mon, 20 Mar 2023 17:56:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1peNU3-0005dj-3a for bug-gnu-emacs@gnu.org; Mon, 20 Mar 2023 17:56:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1peNU2-0006fo-Ik for bug-gnu-emacs@gnu.org; Mon, 20 Mar 2023 17:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1peNU2-0006uR-12 for bug-gnu-emacs@gnu.org; Mon, 20 Mar 2023 17:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Mar 2023 21:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62300 X-GNU-PR-Package: emacs Original-Received: via spool by 62300-submit@debbugs.gnu.org id=B62300.167934935226543 (code B ref 62300); Mon, 20 Mar 2023 21:56:01 +0000 Original-Received: (at 62300) by debbugs.gnu.org; 20 Mar 2023 21:55:52 +0000 Original-Received: from localhost ([127.0.0.1]:56945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1peNTr-0006u3-MP for submit@debbugs.gnu.org; Mon, 20 Mar 2023 17:55:52 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47390) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1peNTp-0006tp-Jo for 62300@debbugs.gnu.org; Mon, 20 Mar 2023 17:55:50 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A252680AD5; Mon, 20 Mar 2023 17:55:43 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E9ABF800A8; Mon, 20 Mar 2023 17:55:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1679349341; bh=I7sp9D4rbHyI6EMNOm5RDgaONKu0RfAdkHpBoiD6r7Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iDBOSGp1iD3/tdS6Rl/QRNK7anwvMYqHRTbjHOfCRDtynGndFYcCexJ4u2tiQQcc1 4vBkZXxv5jDypM2ptnYX2/V1/diIOPWeNhlUhX50LRsyCbx+w5SyVaufZEyFBByEIZ 0b9IDEH5zHdi9QTy9ddvj/B+7GHXFlB3H1aaER9IgzqYFNyfRo5Tp09cvMdpaAdw+T RV+IAF/OzKiVppXtGJAtHL7gQ+8YzTfqUlQ5KaG2HGcTn1ZvyBD6uelOTanKxHR6/4 AchFr0R488fji6G/3GT32Fkfd3kdwL1f+xk4ro6wXEyq0TfVu0oGLK7KFIhu1Zk02A OP1B0GgA/BGFA== Original-Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C1D5E123210; Mon, 20 Mar 2023 17:55:41 -0400 (EDT) In-Reply-To: <83ttyf6ys3.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 20 Mar 2023 20:52:28 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:258324 Archived-At: >> 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 `help-definition-prefixes` and friends (`help-enable-completion-autoload`, ...) are the result of a tradeoff: we offer to autoload files "on demand" but the "demand" is often vague/implicit, so we have to judge when the demand is clear enough to justify loading a file and when it's not. If we're too trigger happy, we can end up auto-loading all the .el files in sight, making Emacs unnecessarily bigger&slower (and increasing the risk that we bump into a file that breaks the convention, such as `c-ts-mode`). In this case, `global-text-scale-adjust` has an explicit autoload in `loaddefs.el` so we already have the docstring needed to display `C-h f global-text-scale-adjust RET` without having to load `face-remap.el`, so `help-enable-completion-autoload` doesn't load `face-remap.el`. >> 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. Among the prefixes registered for `face-remap.el` there is `text-scale-` because there are various other functions beside `text-scale-adjust` which start with `text-scale-`. I'm not completely sure why we end up loading `face-remap.el` here (it doesn't seem necessary since the function is also autoloaded), but this difference in the definition-prefixes is probably the reason for the difference in behavior (apparently completion gets involved somewhere even tho it's not needed). >> (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-") Yup: in `face-remap.el`, all the definitions that aren't known before the file is loaded (i.e. not autoloaded) and whose name starts with "global-text-" also start with "global-text-scale-adjust-", so the definition-prefixes data registers this longer prefix, which is more precise. BTW, this is also related to the part of `C-h f` which loads autoloaded functions when it sees something like \\< or \\[ (this is controlled by `help-enable-autoload`). We could change it so it does it also when it sees `...' in the docstring. Stefan