bug#62099: 29.0.60; Intentional change to *Help* source code links?

[Stephen Berman]

On Sat, 11 Mar 2023 13:36:58 +0100 Stephen Berman <stephen.berman@gmx.net> 
wrote:

> On Sat, 11 Mar 2023 14:11:36 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Date: Fri, 10 Mar 2023 18:10:49 +0100
>>> 
>>> I recently noticed a change in the appearance of links to source files
>>> in *Help* buffers for variable and functions definitions in out-of-tree
>>> builds of Emacs.  In Emacs 28 -Q, the first line of *Help* after typing
>>> e.g. `C-h f map-into RET' looks like this on my system:
>>> 
>>>   map-into is a byte-compiled Lisp function in ‘map.el’.
>>> 
>>> The link is ‘map.el’.  In current Emacs 29 and master, it looks like
>>> this on my system:
>>> 
>>>   map-into is a byte-compiled Lisp function in
>>>   ‘/../home/steve/src/emacs/emacs-29/lisp/emacs-lisp/map.el’.
>>> 
>>> In Emacs 28, the *Help* buffer generated by `C-h v
>>> emacs-repository-version RET' starts like this:
>>> 
>>>   emacs-repository-version is a variable defined in 
>>> ‘/datadisk/steve/src/emacs/emacs-28/lisp/version.el’.
>>> 
>>> In current Emacs 29 and master, it looks like this my system:
>>> 
>>> emacs-repository-version is a variable defined in 
>>> ‘/../home/steve/src/emacs/emacs-29/lisp/version.el’.
>>> 
>>> I regularly build emacs out-of-tree, but I made an in-tree test build of
>>> emacs-29, and there the *Help* buffers look like those in Emacs 28.  I
>>> also note that the files names '/home/steve/src/emacs/...' are symlinks
>>> to '/datadisk/steve/src/emacs/...'.  That the symlinks are prepended
>>> with '/..' in *Help* seems odd.
>>> 
>>> I bisected this change to the following commit:
>>> 
>>> 43b0210f83c38fb91cfcfc5a2d4a8c3131331476 is the first bad commit
>>> commit 43b0210f83c38fb91cfcfc5a2d4a8c3131331476
>>> Author: Lars Ingebrigtsen <larsi@gnus.org>
>>> Date:   Thu Jun 2 13:52:58 2022 +0200
>>> 
>>>     Fix out-of-tree build problems with loaddefs.el
>>>     
>>>     * lisp/Makefile.in ($(lisp)/loaddefs.el): Use the new function.
>>>     
>>>     * lisp/emacs-lisp/loaddefs-gen.el (loaddefs-generate): Pass in
>>>     whether to inhibit a partial build (to make the code more general).
>>>     (loaddefs-generate--emacs-batch): Add a new function specially for
>>>     the Emacs build that has the special rules needed.  (This also
>>>     fixes out-of-tree builds.)
>>>     loaddefs-generate-batch can be used in general for packages etc.
>>>     (loaddefs-generate-batch): Remove the special code for Emacs builds.
>>> 
>>> (Why it took me nine months to consciously register the effect of this
>>> commit is a mystery to me, since I use `C-h f' etc. daily.)
>>> 
>>> While there is no bug report associated with this commit, I found a
>>> thread in emacs-devel that leads up to this commit
>>> (https://lists.gnu.org/archive/html/emacs-devel/2022-06/msg00088.html).
>>> Nothing in that thread indicates that *Help* links were intentionally
>>> changed, so I assume this was not intentional.
>>> 
>>> I note that the links work, it's just the appearance that changed.
>>> The Emacs 28 appearance of function definition links seems best to me.
>>> Why variable definition links are absolute file names I don't know;
>>> I'd prefer for them to look like the function definition links.  And in
>>> fact, they do look that that in Emacs 26 and 27:
>>> 
>>>   emacs-repository-version is a variable defined in ‘version.el’.
>>> 
>>> (I haven't tried to track down when the appearance of variable
>>> definition links changed.)
>>
>> Thank you for your detailed report.  However, I'm not sure I
>> understand the bottom line: is there a bug here or isn't there?  If
>> the links work, and the only issue is how they look, why is that a
>> problem?
>
> It does seem to be an aesthetic issue, not a functional one, but if it
> is an unintended consequence of the above commit, as it seems to be, and
> if it's also an undesirable change, as I think it is (the '/..' prefix
> is at least confusing), then I think it qualifies as a bug, though not a
> high-priority one.  If you agree, then I would ask for it to be left
> open, in case someone wants to try fixing it.  I might try myself,
> though I also have more pressing things to do.

A week or so ago I noticed that source links in *Help* buffers no longer
have the unexpected appearance I described above when I start Emacs with
-Q: the links now just show the source file base name plus extension.
However, I still do see the problem when I start Emacs with my init
file.

Then I rebuilt Emacs from both 43b0210f83c and the immediately preceding
commit c7b7c9d40f9, and in both builds, with -Q, *Help* source links of
functions look like in Emacs 28 (i.e. just base name plus extension),
but while links of variables in 43b0210f83c also show just base name
plus extension (as in Emacs 27), in c7b7c9d40f9 they show the full
absolute file name (as in Emacs 28).

But with my init file, in 43b0210f83c the *Help* links of both functions
and variables begin with '/..' as described above, while in c7b7c9d40f9
the *Help* appear the same as with -Q.  So this reaffirms that the
problem is due to 43b0210f83c.  Perhaps I was mistaken in my OP in
reporting the problem as also occurring with -Q (though I have a clear
memory of testing with -Q).  Be that as it may, I have now bisected my
init file and found the culprit:

(add-to-list 'load-path "~/.emacs.d/srb")

The directory "srb" contains files of my personal Emacs customization
code.  I then symlinked that directory to a location outside of
~/.emacs.d and changed the add-to-list sexp accordingly, and with that
change, the *Help* links in 43b0210f83c (and also in the current code
base) appear the same as with -Q.

In fact, it's not necessary to have an existing directory under
~/.emacs.d; I created ~/.emacs containing just the following line:

(add-to-list 'load-path "~/.emacs.d/test")

where there is no file (or directory) "test" under ~/.emacs.d, and with
this init file the *Help* links are shown starting with '/..' in
43b0210f83c (and the current code base).  I note again that this only
happens with an out-of-tree build.  I haven't yet been able to determine
what part of the change in 43b0210f83c causes this issue.

Steve Berman