bug-gnu-emacs
[Top][All Lists]
Advanced

[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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]