GNU bug report logs - #62099
29.0.60; Intentional change to *Help* source code links?

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Stephen Berman <stephen.berman@HIDDEN>; dated Fri, 10 Mar 2023 17:11:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 62099 <at> debbugs.gnu.org:


Received: (at 62099) by debbugs.gnu.org; 11 May 2023 21:14:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 11 17:14:49 2023
Received: from localhost ([127.0.0.1]:53549 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1pxDcf-0005s9-1G
	for submit <at> debbugs.gnu.org; Thu, 11 May 2023 17:14:49 -0400
Received: from mout.gmx.net ([212.227.15.15]:58637)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stephen.berman@HIDDEN>) id 1pxDca-0005rs-97
 for 62099 <at> debbugs.gnu.org; Thu, 11 May 2023 17:14:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417;
 t=1683839678; i=stephen.berman@HIDDEN;
 bh=MiaF+MFHzAtZolfNfkgLBHAS8lHBrRnTK+nRZrecJoA=;
 h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date;
 b=RHvTMMOASihLk4+M4yL4wSp03IyjuupETAp7Im2qhJ7APGxFabGG5tqFY2TclQYt9
 ptFFhx9TtJrxZhzFR0gCIF2pK3/vqQOYv3O0nxSzLjnPA6k4Wntz7Jl1FxDHrfQoE9
 vKX//+4udTYyqQvnPkBqVwiMszDJAB4QdRwl4+ixnhAGs+mDB+0OGSjPBbBbEOSobS
 yJhO2Ta/o/rMgPzPlDiqvmpgTmgg0wq4GdcRk8ZM43rgXHH2CeYksOFXLoONBYok2k
 Kqn5dfyXy4B6L370UMfIZCO1D5K3E9HEXMJ1n1lNyC4BIf72Vl56GqvLT/UkiX/PJp
 geF/ruXHl5SBQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from strobelfs ([89.246.37.210]) by mail.gmx.net (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MLzBj-1pfHGJ010z-00Hvli; Thu, 11
 May 2023 23:14:38 +0200
From: Stephen Berman <stephen.berman@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#62099: 29.0.60; Intentional change to *Help* source code
 links?
In-Reply-To: <87edpvihw5.fsf@HIDDEN> (Stephen Berman's message of "Sat, 11
 Mar 2023 13:36:58 +0100")
References: <87pm9gv8fa.fsf@HIDDEN> <83sfebwkqv.fsf@HIDDEN>
 <87edpvihw5.fsf@HIDDEN>
Date: Thu, 11 May 2023 23:14:37 +0200
Message-ID: <87ednmmuyq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:EEzA8qJzlWvoBIPRdSDPoqNRGZRuD7y+xmXD3cFW+MVneoqcfgw
 UsTe9zgl/lGPrjlgdQekGZL6bOvH0d83RSh6rayglq3ZFZ2GdEUUovYX98qyLzq/HnfWR6j
 w4rpjYC7FgQocxEm5LbB07UGdtGYb1YHlYlhdLCQ7OFWaaz65TquEFDb7RkgrD5Lr1lyKsA
 HShwIhXQ2ZBjDbHcE2/bA==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:iKgzRyhyShw=;6KqGqlUbC/N0YIZn0XiplUfyzYl
 ozLfSK5caTrmwqeCAjhOcEvvdkerp3eENfSQ9yU4Q50kuvxI2jjiZyZ0/PEvGMI1xUUdC2wpj
 sOe9mGmyUa4gq4rkarxhrNyhb32qCc7g6J6WT0+D2oxlQtJoowpj7pT6Z30RwutU68OznpmIg
 GuaZMkTyYy4o0bmwYT5f+dwrkZfgsc7FXjg3whnD1MokYQ8nunE5X33C5oNh5WP8pC+fv8EmD
 Conr6QUNo4EnIH1WuoQvMbv7ImUvUUF068tGSG1piYzG0STRcUPH2S0ePyX6aLnaJewtV0fnf
 EABZMtXoVF+Ghht+t00oXwGBOxV0GE9BgqEKpNRNmOG4hGShihnikWQbtAiQObd5CdlBRmy8E
 TtZYNAZaUQBaeqAr9uz+cPe+yG5rNUl/bQkUxG2I3DFmDvTHeo8FQyMDmKoCc8kf5qSSZ5rER
 j+S+eD5rRk53U8zT7idzOGA3yuHwlMkI76NYncPfEQE1ByDXvdUtJEhBNVH6YwfeM/VG1PJFm
 zPZ+nazpzB1qF8Qt8ft3b3IYvSSl1gCcNqU+Zq/BPhybWUZwZcVZ1KcJwZELbYvp06M63xbna
 1Bf8GP5NcPevc99qxv0fKxPliv407n6IWevEfU87x+RtYbg5zqGOmuH//yACmEhhnirz5Hm4m
 GJxKAOySNmQ026lVynhodaEzAok1oeMwOrq14bsTO/IoeZ2CARhzHGDQMFwdslyRDGwcxLsev
 hbH/xnLl+Kc6g9NZPeFM7zguMEeumiWDoXgIx+CDEP5c+hb8cJcqv8TYz2R8r0GbJfTz70l2q
 KnFrsUwDcLLLivldoQK99tRiOPn4xXTQ1udcVHGYfz6iFppOn4TH/kRH6hX1g7ZEX4xWPm46J
 Rbgpe1efcdqgz8OHlp4dyq5+ZLh0wtM8fOxpKWCaFnXmF//Bw15JC6tHS4DvZNPNTNdjOZ5vr
 sYxCAg==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 62099
Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 62099 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

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

> On Sat, 11 Mar 2023 14:11:36 +0200 Eli Zaretskii <eliz@HIDDEN> wrote:
>
>>> From: Stephen Berman <stephen.berman@HIDDEN>
>>> Date: Fri, 10 Mar 2023 18:10:49 +0100
>>>=20
>>> 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:
>>>=20
>>>   map-into is a byte-compiled Lisp function in =A1=AEmap.el=A1=AF.
>>>=20
>>> The link is =A1=AEmap.el=A1=AF.  In current Emacs 29 and master, it loo=
ks like
>>> this on my system:
>>>=20
>>>   map-into is a byte-compiled Lisp function in
>>>   =A1=AE/../home/steve/src/emacs/emacs-29/lisp/emacs-lisp/map.el=A1=AF.
>>>=20
>>> In Emacs 28, the *Help* buffer generated by `C-h v
>>> emacs-repository-version RET' starts like this:
>>>=20
>>>   emacs-repository-version is a variable defined in =A1=AE/datadisk/ste=
ve/src/emacs/emacs-28/lisp/version.el=A1=AF.
>>>=20
>>> In current Emacs 29 and master, it looks like this my system:
>>>=20
>>> emacs-repository-version is a variable defined in =A1=AE/../home/steve/=
src/emacs/emacs-29/lisp/version.el=A1=AF.
>>>=20
>>> 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.
>>>=20
>>> I bisected this change to the following commit:
>>>=20
>>> 43b0210f83c38fb91cfcfc5a2d4a8c3131331476 is the first bad commit
>>> commit 43b0210f83c38fb91cfcfc5a2d4a8c3131331476
>>> Author: Lars Ingebrigtsen <larsi@HIDDEN>
>>> Date:   Thu Jun 2 13:52:58 2022 +0200
>>>=20
>>>     Fix out-of-tree build problems with loaddefs.el
>>>=20=20=20=20=20
>>>     * lisp/Makefile.in ($(lisp)/loaddefs.el): Use the new function.
>>>=20=20=20=20=20
>>>     * 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.
>>>=20
>>> (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.)
>>>=20
>>> 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.
>>>=20
>>> 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:
>>>=20
>>>   emacs-repository-version is a variable defined in =A1=AEversion.el=A1=
=AF.
>>>=20
>>> (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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#62099; Package emacs. Full text available.

Message received at 62099 <at> debbugs.gnu.org:


Received: (at 62099) by debbugs.gnu.org; 11 Mar 2023 12:40:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 11 07:40:23 2023
Received: from localhost ([127.0.0.1]:56749 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1payWN-00011C-A8
	for submit <at> debbugs.gnu.org; Sat, 11 Mar 2023 07:40:23 -0500
Received: from eggs.gnu.org ([209.51.188.92]:41628)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1payWL-000110-UQ
 for 62099 <at> debbugs.gnu.org; Sat, 11 Mar 2023 07:40:22 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1payWG-0005Yc-Fu; Sat, 11 Mar 2023 07:40:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=xEU354jetBOf7RoBXQM03sHucEG5ZmFFXBXNm5x1MYQ=; b=EgaWmEZ0m8n1
 GEZ+awvTG4sh4Fj7fARIG8pNjmffdOqhYo2rT3KpT+QYUf/1U8Sl2ONmSwxw33hMYTc7/A79FvNrq
 cVsWOm+AUhnuHigIobEkXjVuWV859QaHn03BDhtz0T0qxIy3Q5vKXa1J5U0fRjsxmCPMlJvbnPp2m
 F4/HOZoIXpEA8q7PpZqbzAUDykJXqxp5N8OzdUBkjYqUujUgR2QBh/Lsg+DTeqzjOH1TSA+udP/1N
 BmmYYTtudIut0996pdXi/h2hbJgHNbbiVyx+IOvXI2FNtSVY+rKtYcMOgrYE+JnngPn+TQdJzyZcE
 MBZOA0Hu5JwNaUSnTucYcg==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1payWF-00063k-L9; Sat, 11 Mar 2023 07:40:15 -0500
Date: Sat, 11 Mar 2023 14:40:01 +0200
Message-Id: <83lek3wjfi.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stephen Berman <stephen.berman@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>
In-Reply-To: <87edpvihw5.fsf@HIDDEN> (message from Stephen Berman on Sat, 11
 Mar 2023 13:36:58 +0100)
Subject: Re: bug#62099: 29.0.60; Intentional change to *Help* source code
 links?
References: <87pm9gv8fa.fsf@HIDDEN> <83sfebwkqv.fsf@HIDDEN>
 <87edpvihw5.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62099
Cc: 62099 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stephen Berman <stephen.berman@HIDDEN>
> Cc: 62099 <at> debbugs.gnu.org
> Date: Sat, 11 Mar 2023 13:36:58 +0100
> 
> > 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.

Maybe Lars (CC'ed) can tell if this is intended or not.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#62099; Package emacs. Full text available.

Message received at 62099 <at> debbugs.gnu.org:


Received: (at 62099) by debbugs.gnu.org; 11 Mar 2023 12:37:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 11 07:37:09 2023
Received: from localhost ([127.0.0.1]:56744 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1payTE-0000wC-FT
	for submit <at> debbugs.gnu.org; Sat, 11 Mar 2023 07:37:08 -0500
Received: from mout.gmx.net ([212.227.15.15]:56959)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stephen.berman@HIDDEN>) id 1payTC-0000vi-G1
 for 62099 <at> debbugs.gnu.org; Sat, 11 Mar 2023 07:37:07 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417;
 t=1678538220; i=stephen.berman@HIDDEN;
 bh=3qntimhB17hpMPj22uVks9XLKDmXKOI+S6ZYisCclrA=;
 h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date;
 b=UqVfBHA404LhJUYcb4pamnj8Q0wyQpEBz9cVtsTeLJFbTWBMWLrtq5gcRoWvDN+D/
 K4Dy4V3CGrTpAmkitX9Xv3s8TJtwqhjJ9eohVA1Wb18giKhzrG9jIl/sWBU6iqQ3ma
 FJHMrI6ctk8DLVRIxHqpKDfgFtHdXOxQr03GeXFponV4f+hMry4qpLQyiuUvb//tZl
 3ki/Cf6T4VESkQrxAZf3ggULBm39UjS6WCKoDx7+gqCyBj1IauUUZ9sPFtSWC/VUPX
 hyvkIRbIcQERcWiyKIzuTec5dsSCxtz4cyVjx1dDu2F7lWUV2HEOTkm+O0Ski+GpLh
 SV7E/0E0LgEeQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from strobelfssd ([94.134.196.119]) by mail.gmx.net (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M2f5Z-1pYVMJ0qHX-0047tS; Sat, 11
 Mar 2023 13:37:00 +0100
From: Stephen Berman <stephen.berman@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#62099: 29.0.60; Intentional change to *Help* source code
 links?
In-Reply-To: <83sfebwkqv.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 11 Mar
 2023 14:11:36 +0200")
References: <87pm9gv8fa.fsf@HIDDEN> <83sfebwkqv.fsf@HIDDEN>
Date: Sat, 11 Mar 2023 13:36:58 +0100
Message-ID: <87edpvihw5.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:yBLOw1CSKsZf+uDvMi9LJTlatXqCaRCDv6gNUTHv1/+j/xDkFs0
 M2JZ2BYJpJKz3FXvUhZWSCS5Orn3r84mTCqyHpkbMn3kgk1fiYhBTfWtfWBd23mUA25kJ3j
 ROX8j4j69zWafBj8TuabZfJs0+PjxcLncPVK9VnOpFc530bnePGIuAgmGa6fRbOwbTRvSTj
 UyEZXpoOkjiAusEGr/7Sg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:zcSpXD1qsW8=;/jO2lmkC7W5V25njiEB+xAIfYta
 sj7JB+GNTaGy0OBJw5Wg+2AR+DpqI7YoILhNluy1tcP3hWSAAigbDXk5p+fpiZ/NpAepM7tf3
 WEil75AARS1/qh5XRRC4O1D2fT3J3tkjh0Kytj474cRIthN+sWTvfFEmOU5SqAsXtKZKiCENG
 uhngJ9y5OUr67nireklNHcSpo4Z2FLbawIkPtxpALCHDlBr+cui43Jxa+TjemvNxq+ewJ1wWK
 fkhwEh+LPg6JclSN/gIAjmFsMpdiVupedq+NLE5h2MfqBLE8jGcJb4xSnZddb91cyz5ntQ7yx
 IwWo5hJCaa6dgHvtyut9ANtvNPDq9z9i+a0Zr0vBreFuOjPY47TYLvGlwruy5gxPX2Vi6xqcQ
 6HnjOjRq1ciuNFQBnjEFIJAAVeXxzZ7fpSIkZgcm9FLTVeuZMF/K/5ddkeYPpvWB6AeFaay6D
 gORkSQri3T/oMvBBVhkW3XVwLdTUldcfB/kifG5UczVRkz0ddfD7BMtV1+gURLLavuLZj1NG6
 BVzjVv7AWvwgmkis11VCYgDJMBWj+trlOcvIysp/rc6hZwjn+NmYfMGPuRiF7FQlyXmlP/yH4
 9/dnSAf/Mr2VlyAuBwfZd3y4KF/bBo+tUgWLA9GrKTEhBXFZUTsqUv7cEBwuxS0uWTVyVZT80
 ICKu+WFywvKZidUk4y7+jLfCTKimXVDE0gB823U9MYixfy9HbzSoJLDcp/eEBu00iGVY4LW42
 tyBzbvz1oL0+mEw8EAOJBSf+wbkQnQ70hyU9kkHC6PEKRrIT7wEeB2mgJL6/jwfgrbiKTe/ly
 eO6HjLvBFEylcoH1oR4NywHKNhaEK/skpLkqAecaGl22YJ5fv6ToCsdL7prXeBHw3pBPlpLLq
 KjnbLrSiVoDr4+9fZPDuvTWqeoV9wt8R5GKso5T6wL2O0r9iqsg4Xi7w5zaF9r8juCFJUD+Gk
 bYCzApJCLYbpaWT01AaVCg7ql4k=
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 62099
Cc: 62099 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

On Sat, 11 Mar 2023 14:11:36 +0200 Eli Zaretskii <eliz@HIDDEN> wrote:

>> From: Stephen Berman <stephen.berman@HIDDEN>
>> Date: Fri, 10 Mar 2023 18:10:49 +0100
>>=20
>> 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:
>>=20
>>   map-into is a byte-compiled Lisp function in =E2=80=98map.el=E2=80=99.
>>=20
>> The link is =E2=80=98map.el=E2=80=99.  In current Emacs 29 and master, i=
t looks like
>> this on my system:
>>=20
>>   map-into is a byte-compiled Lisp function in
>>   =E2=80=98/../home/steve/src/emacs/emacs-29/lisp/emacs-lisp/map.el=E2=
=80=99.
>>=20
>> In Emacs 28, the *Help* buffer generated by `C-h v
>> emacs-repository-version RET' starts like this:
>>=20
>>   emacs-repository-version is a variable defined in =E2=80=98/datadisk/s=
teve/src/emacs/emacs-28/lisp/version.el=E2=80=99.
>>=20
>> In current Emacs 29 and master, it looks like this my system:
>>=20
>> emacs-repository-version is a variable defined in =E2=80=98/../home/stev=
e/src/emacs/emacs-29/lisp/version.el=E2=80=99.
>>=20
>> 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.
>>=20
>> I bisected this change to the following commit:
>>=20
>> 43b0210f83c38fb91cfcfc5a2d4a8c3131331476 is the first bad commit
>> commit 43b0210f83c38fb91cfcfc5a2d4a8c3131331476
>> Author: Lars Ingebrigtsen <larsi@HIDDEN>
>> Date:   Thu Jun 2 13:52:58 2022 +0200
>>=20
>>     Fix out-of-tree build problems with loaddefs.el
>>=20=20=20=20=20
>>     * lisp/Makefile.in ($(lisp)/loaddefs.el): Use the new function.
>>=20=20=20=20=20
>>     * 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.
>>=20
>> (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.)
>>=20
>> 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.
>>=20
>> 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:
>>=20
>>   emacs-repository-version is a variable defined in =E2=80=98version.el=
=E2=80=99.
>>=20
>> (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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#62099; Package emacs. Full text available.

Message received at 62099 <at> debbugs.gnu.org:


Received: (at 62099) by debbugs.gnu.org; 11 Mar 2023 12:11:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 11 07:11:59 2023
Received: from localhost ([127.0.0.1]:56700 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1pay4t-0006Ij-61
	for submit <at> debbugs.gnu.org; Sat, 11 Mar 2023 07:11:59 -0500
Received: from eggs.gnu.org ([209.51.188.92]:43142)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1pay4r-0006IQ-V0
 for 62099 <at> debbugs.gnu.org; Sat, 11 Mar 2023 07:11:58 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1pay4m-00086f-BM; Sat, 11 Mar 2023 07:11:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=uvreLrp5OqOmIlpUw4fNwhTXnil9e3vbkFdjsXZyqbE=; b=EomJ8mU3T2fseLGxf9MZ
 AMWa9CJQNQUEy9lDoLvhcoRhHSuzcX1PhTtARJayWOUCmqaOu5CrCQ3bHnEnEMX+BBITp6cNYl33b
 urUHOjuXqx7fmvIxk6/K5jrM4ufO2vyb8pIGUdtDsyxoCbFAmw5xRIvkipZeFBXYWswHD9HyvKUuY
 j99D3sweInwiByZST565MaXMSjEhYff+MUsMTnP2tXITBOQHRMrPOaN9S1zRlc5d2nQhMbLIMUMuL
 N3jDc7H+GXvLnt61NZJuis3KWZBuuSAg+2meeVKOF5tCEP7AN5sdOBFGpbbpa1rYJmCNj83lBeHWg
 4scosMWP5Zcs7g==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1pay4l-0007a2-HS; Sat, 11 Mar 2023 07:11:51 -0500
Date: Sat, 11 Mar 2023 14:11:36 +0200
Message-Id: <83sfebwkqv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stephen Berman <stephen.berman@HIDDEN>
In-Reply-To: <87pm9gv8fa.fsf@HIDDEN> (message from Stephen Berman on Fri, 10
 Mar 2023 18:10:49 +0100)
Subject: Re: bug#62099: 29.0.60;
 Intentional change to *Help* source code links?
References: <87pm9gv8fa.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62099
Cc: 62099 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stephen Berman <stephen.berman@HIDDEN>
> 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@HIDDEN>
> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#62099; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 10 Mar 2023 17:10:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 10 12:10:59 2023
Received: from localhost ([127.0.0.1]:55691 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1pagGg-0002md-VD
	for submit <at> debbugs.gnu.org; Fri, 10 Mar 2023 12:10:59 -0500
Received: from lists.gnu.org ([209.51.188.17]:57270)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stephen.berman@HIDDEN>) id 1pagGf-0002mV-G0
 for submit <at> debbugs.gnu.org; Fri, 10 Mar 2023 12:10:58 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <stephen.berman@HIDDEN>)
 id 1pagGf-0000wn-6m
 for bug-gnu-emacs@HIDDEN; Fri, 10 Mar 2023 12:10:57 -0500
Received: from mout.gmx.net ([212.227.17.22])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <stephen.berman@HIDDEN>)
 id 1pagGb-0008IP-Vy
 for bug-gnu-emacs@HIDDEN; Fri, 10 Mar 2023 12:10:56 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417;
 t=1678468250; i=stephen.berman@HIDDEN;
 bh=9ph1UJWLWmzuP0JUZagAnBatsHDSPvNMIXAw+8dozs4=;
 h=X-UI-Sender-Class:From:To:Subject:Date;
 b=saU4jvegm4a1YbXiTDlP3Vggz+LFGYphBxJ+Nc5Fh5Ky/ayfEuEEiK7pw6lGDouCc
 Qp4TaYS/cbXu4LzwHdZLMTcvJf5R76OcEz62ldjImEs3ZITiTM4xbEuYIgMJ2ov2+r
 g+mzgLkr0jT5IBsmdQzBXg2xJY2F+/DLMKls1gFnUD3r3F8t4QCZreUxSj3S8h7siR
 QJKC7syRrhScHGK0s3jIqnGLvirQlWnZwXML+dyIY4LuX/7r+TRTSDkknScwF/msuf
 SAgDFfQxyXtGRXJvqbXXWv1OpOsOMOKrS+60nT8UU6HkuHyXKknTcXYhEDmwic6U96
 qFZJwP9qsDR/Q==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from strobelfs ([94.134.196.73]) by mail.gmx.net (mrgmx105
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MJE27-1ppCLJ2OjL-00Kfym for
 <bug-gnu-emacs@HIDDEN>; Fri, 10 Mar 2023 18:10:50 +0100
From: Stephen Berman <stephen.berman@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 29.0.60; Intentional change to *Help* source code links?
Date: Fri, 10 Mar 2023 18:10:49 +0100
Message-ID: <87pm9gv8fa.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:n9pcwMKHpck9jM+ZgJaYO6HxUy40PTa21WcavhZMxetL9w4wtQZ
 TIvve1+e/OQOWjSC/8oMNydu+cSdlaC42DmadMc3TwWLsS+HAIBaMx5RRCKGsOUGGwk6xgv
 szcED467ywndMMwoMIuC9KGKm3Plck29iLrUyp46qStZ/vint6OkNR0Ap1fRhLXiPsdPEHf
 nQQUqCdslXzlYnD9YiW+Q==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:1ypqd7zia/k=;9AgbmcM9PuZcmDMIVC2eweXJFag
 EyLh+rMF6djwEEbseQmhTwV8+MRFpk8A9ucTbkQ7i/7qAoleh6t7d2L5Pu6MBeZadOVTFAxh8
 rvjZvnaEF3onRTitv0sUYZ9x3a0l4mE8QZZ1+i568M0wIobuFpCnH/8J20zjwLOh8o7V60YZa
 v9NqbgU303IOzeCSH6y7giveZpTVARGoae/kXZewhn/ZA9shPiolkntnSneNHr/mceThffmCY
 pNF13mC1Mhnn8Z1fnZ1oyx4DYPg8dFR3iKnRxY3zpSytZzILAtI0b4yRGlPtp1UJ8yPMfdah4
 5orATeuVkyFkad65xAKny8TY62YVUTpeI2SKRVQZuwyHhTKernyArqB3VtlGNYsWck3SnPzwS
 xXP4VTrF29pwptl9Hzaa+tp1tZCiBQTmcIaBiI0c2WE1q2brvDptO2Wg8+zc4z1UuDOI5WOn0
 g3ziq7i1+HmvsKd85hWrW3G2xZEmB+RA2uml4ZbHp1mFj8Nb5D3lDD2dkeRC8PniwamtPgxsm
 P8fJilhK7/Jn+hewNnN5ZmP1rD6TwXpGjm5Fnd1ntE9PPIR0NnilCuE9qsZGWbk18ygK6caA2
 3GGKOca1z4ZeRv9HyY0kEZZV+l0mlzrHPCFjzb2NenZxb2hCTqs5zPVlEU5uq4gX/autj4jIP
 uXLVWHcCHfeOKy+oHKzLhak2IdkhfRCldBEAa0YfnoekIT/dsZsC/mbkVz2QvuYg5xy1pBUNj
 EvxHjXxGOmW6UzXcBm8f5k1HJctGvMHAF+W1ow/M50VBQaRQ90uOoVuCoHhpLUNskdbsggr7n
 nJoonCWlaRMD2F3D7EdC5fNyqjwG4eX80TanRdfYecuwrqES1q2rofA5KAHap4vaOtg5uHYt3
 JroFJm/6TGKyk3JcHelYKZBw68qZMX+tdwhtp+iYTfWDL/SISPCBjd25mUyPStKyHYPmiLxJS
 bVLJKM5hRtVCZHnqFIUPZXaUGnM=
Received-SPF: pass client-ip=212.227.17.22;
 envelope-from=stephen.berman@HIDDEN; helo=mout.gmx.net
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)

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 =A1=AEmap.el=A1=AF.

The link is =A1=AEmap.el=A1=AF.  In current Emacs 29 and master, it looks l=
ike
this on my system:

  map-into is a byte-compiled Lisp function in
  =A1=AE/../home/steve/src/emacs/emacs-29/lisp/emacs-lisp/map.el=A1=AF.

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 =A1=AE/datadisk/steve/s=
rc/emacs/emacs-28/lisp/version.el=A1=AF.

In current Emacs 29 and master, it looks like this my system:

emacs-repository-version is a variable defined in =A1=AE/../home/steve/src/=
emacs/emacs-29/lisp/version.el=A1=AF.

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@HIDDEN>
Date:   Thu Jun 2 13:52:58 2022 +0200

    Fix out-of-tree build problems with loaddefs.el
=20=20=20=20
    * lisp/Makefile.in ($(lisp)/loaddefs.el): Use the new function.
=20=20=20=20
    * 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 =A1=AEversion.el=A1=AF.

(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=3D-Og -g3'
 PKG_CONFIG_PATH=3D/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




Acknowledgement sent to Stephen Berman <stephen.berman@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#62099; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Thu, 11 May 2023 21:15:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.