[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62099: 29.0.60; Intentional change to *Help* source code links?
From: |
Eli Zaretskii |
Subject: |
bug#62099: 29.0.60; Intentional change to *Help* source code links? |
Date: |
Sat, 11 Mar 2023 14:11:36 +0200 |
> 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?