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

[Stephen Berman]

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


In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.36, cairo version 1.17.6) of 2023-03-07 built on strobelfs
Repository revision: bd07cec844257ba8ae95b2ab2e66982360576c9d
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Linux From Scratch r11.2-332

Configured using:
 'configure -C --with-xwidgets 'CFLAGS=-Og -g3'
 PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/opt/qt5/lib/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP
X11 XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB