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
bug-gnu-emacs@HIDDEN:bug#62099; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#62099; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#62099; Package emacs.
Full text available.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?
bug-gnu-emacs@HIDDEN:bug#62099; Package emacs.
Full text available.
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
Stephen Berman <stephen.berman@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#62099; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.