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

[Stephen Berman]

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.

Steve Berman