Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 62099) by debbugs.gnu.org; 15 May 2023 11:56:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 15 07:56:37 2023 Received: from localhost ([127.0.0.1]:42917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pyWoe-000550-Nv for submit <at> debbugs.gnu.org; Mon, 15 May 2023 07:56:37 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58380) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pyWoa-00054h-Ez for 62099 <at> debbugs.gnu.org; Mon, 15 May 2023 07:56:36 -0400 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 1pyWoT-00026o-A0; Mon, 15 May 2023 07:56:26 -0400 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=L+urfowdcXHlaIwOwriXRa86lFuREOQxhmWwfG62MbA=; b=rGnVIPbj6jUw n6dXVJ/8zJaBwn2O8Sc2sIDI7xpZTJBzXI1dr/G8lOnfD/UueC21nsHr/HkP1inS1mkayxtBTybxW NfsIRDaLYTMYY2MTvagX6rbhbax0i6z5MyflHkOmcynv/liBqNvftZUShJuRWr1yMG1n5mzyg3z7A 7Plw5xBONn67sgS4xKsxXg10V2NNsEjLSLfUT6nv5IGbAGy5K6f50XijfIW83uIW542XGOJYO57UK Lb3tbMtYJMwklewysdbSCy8AxbKfKxw5x7cFnb1m80JHLCuq8xHeXkCzs07eKcXkqOqzCavdhkQNu wFGlE8ZM2U3Pe72lTNYUXg==; 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 1pyWoA-0001RD-SD; Mon, 15 May 2023 07:56:21 -0400 Date: Mon, 15 May 2023 14:56:11 +0300 Message-Id: <83fs7x24h0.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stephen Berman <stephen.berman@HIDDEN> In-Reply-To: <87y1lqa4qe.fsf@HIDDEN> (message from Stephen Berman on Mon, 15 May 2023 01:11:05 +0200) Subject: Re: bug#62099: 29.0.60; Intentional change to *Help* source code links? References: <87pm9gv8fa.fsf@HIDDEN> <83sfebwkqv.fsf@HIDDEN> <87edpvihw5.fsf@HIDDEN> <87ednmmuyq.fsf@HIDDEN> <83o7mq3xnp.fsf@HIDDEN> <87353yc2do.fsf@HIDDEN> <83lehqu7y7.fsf@HIDDEN> <87y1lqa4qe.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62099 Cc: 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: -3.3 (---) > From: Stephen Berman <stephen.berman@HIDDEN> > Cc: 62099 <at> debbugs.gnu.org, larsi@HIDDEN > Date: Mon, 15 May 2023 01:11:05 +0200 > > On Sun, 14 May 2023 20:41:20 +0300 Eli Zaretskii <eliz@HIDDEN> wrote: > > >> 43b0210f83c only changed how loaddefs.el is generated, and for > >> out-of-tree builds, also how the names of the files under lisp are > >> represented in loaddefs.el. Prior to the change, in out-of-tree builds > >> these file names appeared the same as those in in-tree builds, e.g.: > >> > >> ;;; Generated autoloads from play/5x5.el > >> > >> But after 43b0210f83c, in my out-of-tree builds, they now look like > >> this: > >> > >> ;;; Generated autoloads from > >> ../../../../../../home/steve/src/emacs/test-29/lisp/play/5x5.el > > > > Isn't the above difference the root cause, right there? Why should > > the output in loaddefs.el depend on whether this is an in-tree or > > out-of-tree build? Eventually, when the produced loaddefs.el is > > installed, the *.el files from the tree and the *.elc files from both > > the tree and out-of-tree will end up in the same directory, so there > > should be no ../../../.. etc. in the file names recorded in > > loaddefs.el, they should be all relative to <source-directory>/lisp, > > no? > > I'm not sure I understand: there are no *.elc files in the out-of-tree > build directory, all byte-compiled files reside in the source tree > together with the *.el files. Also, FWIW I do not install my Emacs > builds and haven't tested whether the problematic file names appear in > an installed build. These aspects don't matter. My point is that the format of file names in loaddefs.el should not depend on whether it is an in-tree or out-of-tree build. If you don't agree, please explain why. > > It seems like loaddefs-gen.el does this instead: > > > > (let* ((relfile (file-relative-name > > (cadar section) > > (file-name-directory loaddefs-file))) > > (head (concat "\n\f\n;;; Generated autoloads from " > > relfile "\n\n"))) > > > > which uses the wrong directory as the second arg of > > file-relative-name. > > > > Am I missing something? > > Well, for one thing this part of the code was not touched by > 43b0210f83c. I don't think this matters, either. If the same code produces two different results in these two revisions, then either the first or the second argument (or both) to file-relative-name were modified by commit 43b0210f83c. I think we should find out which change caused that, and then try to fix that so that the results are identical. > Also, while I haven't found a way to step through > loaddefs-generate while loaddefs.el is being generated, since that's > part of the build process, note that evaluating the following sexp: > > (file-relative-name "/datadisk/steve/src/emacs/test-29/lisp/play/5x5.el" "~/build/test-29/lisp/play") > > produces the same number of "../" as appear in loaddefs.el: > > "../../../../../../datadisk/steve/src/emacs/test-29/lisp/play/5x5.el" Why is that important? Wed don't suspect a bug in file-relative-name, do we? Again, my point is that the second argument to file-relative-name should not be the build directory, it should be the source directory. > The difference is that loaddefs.el has "home" instead of "datadisk". > But on my system, ~/src is a symlink to /datadisk/steve/src. Perhaps > this an irrelevant coincidence, but I found it striking in this context. Why striking? And why do you think it's important for fixing this problem? > > Or maybe step through the code in autoloads.el and see how it succeeds > > in computing the correct relative file name even in out-of-tree > > builds, and let's take it from there. > > Do you mean autoload.el? But this file was obsoleted in commit > 22a2ad13f50 not long after commit 43b0210f83c and I believe > loaddefs-gen.el is meant to be its replacement. Sure, but it did the job, didn't it? You could as an alternative step through loaddefs-gen.el before commit 43b0210f83c, and see what happened there. The idea is to see what should be the correct value of relfile and why doesn't the current code yield that. > > However, I think we should concentrate on the first place with the > > deviation, which I think is loaddefs.el. > > I'm not sure: it seems to me those file names with "../../../../../../" > are intended, in order, as the commit message of 43b0210f83c says, to > "Fix out-of-tree build problems with loaddefs.el". What are those problems? And why does using "../../.." fix them?
bug-gnu-emacs@HIDDEN:bug#62099; Package emacs.
Full text available.Received: (at 62099) by debbugs.gnu.org; 14 May 2023 23:11:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 14 19:11:14 2023 Received: from localhost ([127.0.0.1]:42302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pyKry-0005R3-0N for submit <at> debbugs.gnu.org; Sun, 14 May 2023 19:11:14 -0400 Received: from mout.gmx.net ([212.227.17.20]:41805) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <stephen.berman@HIDDEN>) id 1pyKrw-0005Qk-9Q for 62099 <at> debbugs.gnu.org; Sun, 14 May 2023 19:11:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1684105865; i=stephen.berman@HIDDEN; bh=MkGCwM4lUlqEziFMIQMn3s5p5L95JwOUn4J1e6VSAFQ=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=iKyzJC/j7mU06zId7Cx/QARaa+8SnGzYLvp8Iu/BxlB484dfGIx3EfwdUZHbD0Bz7 qSQ0kAVKNd21xyutIvzvL0zxoSfx8hjeRMKg02jdqzk6N4PvSIIk7lXeQfjnlndPDj B6xb6tHII26w4ZPVRaUtlo78FhvI8d+C9RlsOfz1NsQrWMb8JSliCDiGs8oWbjYiHI 5sMx70uoXwTmlATNOh/ARSqmZk23X4qRw6vdlM1PgwGbQWrva98Xo6avHNPO9HMy3e baRqifFexGKepffpzQN3WvueJdYU2ERIFfbD7Qbojky69BK76CRBcXofssl1FKscK1 nL0EI8xEEmHdQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from strobelfs ([94.134.196.122]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MqJqN-1qTWlW3ByN-00nPqa; Mon, 15 May 2023 01:11:05 +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: <83lehqu7y7.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 14 May 2023 20:41:20 +0300") References: <87pm9gv8fa.fsf@HIDDEN> <83sfebwkqv.fsf@HIDDEN> <87edpvihw5.fsf@HIDDEN> <87ednmmuyq.fsf@HIDDEN> <83o7mq3xnp.fsf@HIDDEN> <87353yc2do.fsf@HIDDEN> <83lehqu7y7.fsf@HIDDEN> Date: Mon, 15 May 2023 01:11:05 +0200 Message-ID: <87y1lqa4qe.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:BnzdjwgKsa5U3cXAoI/q0ToKEZVJuwuLtt1p+TP3116iTOlO0S7 cak/U4j0FrcDWDUvfUoheLKphWuShb50/IJMk4Rz2hM4HFDTq6jL3Zf6D0rYP73QMrVc7JV tmevBgOqTlHd+jsYb3lOLLjYyR5I5qnDnWGMPzppxJriynR6VNxYto2IUSSmojz/vsXq9VG cetMLnT66cqr/mEbDlu0w== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:/Jskl5Fkpo4=;XRwYtNh0AQ1dYFj7ElOjjT3toW2 uMY4/VgP9l/c58FJ+JprF+AEWzF1D0dHlLAzO+Wb8WpXO4w08huSxpWMe9T5BqyqSYDAjf3Eo ADurKKVbiRZoGYP8RgZQzgBDWpMuiAyDTHgBJgYeoIdYeAPbCpC5QSMiUY3CKt6sN7V7n5pyg 1AQj02/MHdBxK8oZXCBEZM6C+Klyn/xyqwcOJkTVkAsxMaq0WpE+uujw9Sme1/hyGa9cPG+61 gNM8Lm8sSnDIRO/q+fVXi1RghEg5tOShwIFfppsLyFPY0qRvZnvs+Ey6b+vO85vcNeIn77lhi 9AlbnDyAg6gj0F+eI3zLGuVD0SEgvG7ETKbDVN17kGglNCEefN9eTeQr1340xlD3dJneC07ng KNkH1Q4b1o3CaLM/P5BH77ma4QOXT+vP9hZ5OPOVGEPRqzU+PxTXD6jFhDt0zWQZ1IpMjPkxM 8EZ9QLUfkqfB4dctyvoMaw7VgSX62rtS83t+onZGKbc4TjK8ewVTiKiUn1YpLWdxKqIkgHiWe nbeiA11YiNTcQOzDPCc9jxHEPwggUNkx78gODLAX4M+PNbqJxvmg1hd/2H/g7WcBHX32VOVDz UOeYve0gS5PHxI9Q8mdxd4EvYQZ4xKDseA8uTv3QaMfXhYhyv39EKB+rhlemUeD+wGZPQAmnB 9oXcxCczKlzJnPB7x8Cty1vkmH1rwBA8nrWKlyahEcDWHp+fbt+qWlGXqvntdH9rqfOHUnI1n vRp+wdO2Pb5zO7+8E3qQl9hJTy4fahAAu6V2WYNtNELEvI2N6F/b9bCOeCQN4gUYQHfILgDds I4BRZMZLr4t5mMFp+QwHmnd1/a5O3KJhfWjIrYoijxh1wY9bVFT0FwkA22T3Rs3ucQTXUyBTy +ne/jaPbQn6f0cuzYzMTDQeOI/tROfV+VhKZ3YERLkUXu/Z8/RjnXfyttdSqiWIL06axuKj78 BvEMjyD4hzef7whOQsQhmaW47II= Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 62099 Cc: 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 Sun, 14 May 2023 20:41:20 +0300 Eli Zaretskii <eliz@HIDDEN> wrote: >> From: Stephen Berman <stephen.berman@HIDDEN> >> Cc: 62099 <at> debbugs.gnu.org, larsi@HIDDEN >> Date: Sun, 14 May 2023 18:18:59 +0200 >> >> > Well, if you could find out the offending code, it will be >> > appreciated. >> >> 43b0210f83c only changed how loaddefs.el is generated, and for >> out-of-tree builds, also how the names of the files under lisp are >> represented in loaddefs.el. Prior to the change, in out-of-tree builds >> these file names appeared the same as those in in-tree builds, e.g.: >> >> ;;; Generated autoloads from play/5x5.el >> >> But after 43b0210f83c, in my out-of-tree builds, they now look like >> this: >> >> ;;; Generated autoloads from >> ../../../../../../home/steve/src/emacs/test-29/lisp/play/5x5.el > > Isn't the above difference the root cause, right there? Why should > the output in loaddefs.el depend on whether this is an in-tree or > out-of-tree build? Eventually, when the produced loaddefs.el is > installed, the *.el files from the tree and the *.elc files from both > the tree and out-of-tree will end up in the same directory, so there > should be no ../../../.. etc. in the file names recorded in > loaddefs.el, they should be all relative to <source-directory>/lisp, > no? I'm not sure I understand: there are no *.elc files in the out-of-tree build directory, all byte-compiled files reside in the source tree together with the *.el files. Also, FWIW I do not install my Emacs builds and haven't tested whether the problematic file names appear in an installed build. > It seems like loaddefs-gen.el does this instead: > > (let* ((relfile (file-relative-name > (cadar section) > (file-name-directory loaddefs-file))) > (head (concat "\n\f\n;;; Generated autoloads from " > relfile "\n\n"))) > > which uses the wrong directory as the second arg of > file-relative-name. > > Am I missing something? Well, for one thing this part of the code was not touched by 43b0210f83c. Also, while I haven't found a way to step through loaddefs-generate while loaddefs.el is being generated, since that's part of the build process, note that evaluating the following sexp: (file-relative-name "/datadisk/steve/src/emacs/test-29/lisp/play/5x5.el" "= ~/build/test-29/lisp/play") produces the same number of "../" as appear in loaddefs.el: "../../../../../../datadisk/steve/src/emacs/test-29/lisp/play/5x5.el" The difference is that loaddefs.el has "home" instead of "datadisk". But on my system, ~/src is a symlink to /datadisk/steve/src. Perhaps this an irrelevant coincidence, but I found it striking in this context. > Or maybe step through the code in autoloads.el and see how it succeeds > in computing the correct relative file name even in out-of-tree > builds, and let's take it from there. Do you mean autoload.el? But this file was obsoleted in commit 22a2ad13f50 not long after commit 43b0210f83c and I believe loaddefs-gen.el is meant to be its replacement. >> I traced the problematic appearance of links in *Help* through the call >> chain describe-function -> describe-function-1 -> >> help-fns-function-description-header -> find-lisp-object-file-name -> >> symbol-file, and symbol-file gets the file name from load-history. In = a >> fresh Emacs, started with a triggering init file, load-history contains >> only standard absolute file names, but when I type `C-h f' and then >> evaluate load-history again, it now contains problematic files names >> like "/../home/steve/src/emacs/test-29/lisp/help-fns.elc". I set a >> breakpoint in gdb on build_load_history, but when I hit it after typing >> `C-h f' and started stepping through the function, the first opportunit= y >> I had to evaluate its argument `filename' already showed the problemati= c >> form. Then I set a breakpoint on readevalloop, the caller of >> build_load_history in lread.c, but again, the first opportunity I had t= o >> evaluate readevalloop's argument `sourcename', which is passed to >> build_load_history, already showed the problematic form. I don't know >> where else to look to try and find out how such forms get into >> load-history. > > It is possible that these are computed by temacs as part of the build, > so the dumped Emacs gets them already cooked. I don't think this can be the case, since the problematic file names do not show up in load-history when Emacs is started with -Q but only when started with a triggering init file, and it's the same temacs in both cases. > However, I think we should concentrate on the first place with the > deviation, which I think is loaddefs.el. I'm not sure: it seems to me those file names with "../../../../../../" are intended, in order, as the commit message of 43b0210f83c says, to "Fix out-of-tree build problems with loaddefs.el". I don't remember if the discussion in emacs-devel leading up to that commit clarifies the matter; I need to read through it again. Steve Berman
bug-gnu-emacs@HIDDEN:bug#62099; Package emacs.
Full text available.
Received: (at 62099) by debbugs.gnu.org; 14 May 2023 17:41:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 14 13:41:27 2023
Received: from localhost ([127.0.0.1]:41398 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pyFio-0001dD-PC
for submit <at> debbugs.gnu.org; Sun, 14 May 2023 13:41:27 -0400
Received: from eggs.gnu.org ([209.51.188.92]:50144)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1pyFim-0001d1-OH
for 62099 <at> debbugs.gnu.org; Sun, 14 May 2023 13:41:25 -0400
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 1pyFih-00035P-49; Sun, 14 May 2023 13:41:19 -0400
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=26a68WhjzzS/O2JCfoODhBw1EppLxO1w6n13sJRD8jg=; b=QCEsz72owBGQ
04kAuDKddCipoLxvQLLDzj2s4tGJUY3Q9jyLkvvjGfPNHS8LKqD9C8F+8sj29/Hh/h2LlZf/zXCHK
EOUvEBC8LPMtmcvzVk9L5gEUR6onDEQMjAAUmNBc6iH7QIOXw/U5KqdWKjNegQyt6wW8kzSP4Esn/
yBnYgjJjWR37B9OBxdfGRDd47YrMRTfFgTWdsOr4HZVYaYA87B4UGyd61d56stdEkMkWfrMW/3qyl
A0M+V6f/YDUhTQJI0p/mji2HyLBTd/j3pVJCX3M0VYrzEpEd8qDp5U2yYG6FRkVUvTWy59CydPkgY
tNKURnnyWIFQgOeF6D5+UQ==;
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 1pyFig-0005Sl-JV; Sun, 14 May 2023 13:41:18 -0400
Date: Sun, 14 May 2023 20:41:20 +0300
Message-Id: <83lehqu7y7.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stephen Berman <stephen.berman@HIDDEN>
In-Reply-To: <87353yc2do.fsf@HIDDEN> (message from Stephen Berman on Sun, 14
May 2023 18:18:59 +0200)
Subject: Re: bug#62099: 29.0.60; Intentional change to *Help* source code
links?
References: <87pm9gv8fa.fsf@HIDDEN> <83sfebwkqv.fsf@HIDDEN>
<87edpvihw5.fsf@HIDDEN> <87ednmmuyq.fsf@HIDDEN>
<83o7mq3xnp.fsf@HIDDEN> <87353yc2do.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 62099
Cc: 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: -3.3 (---)
> From: Stephen Berman <stephen.berman@HIDDEN>
> Cc: 62099 <at> debbugs.gnu.org, larsi@HIDDEN
> Date: Sun, 14 May 2023 18:18:59 +0200
>
> > Well, if you could find out the offending code, it will be
> > appreciated.
>
> 43b0210f83c only changed how loaddefs.el is generated, and for
> out-of-tree builds, also how the names of the files under lisp are
> represented in loaddefs.el. Prior to the change, in out-of-tree builds
> these file names appeared the same as those in in-tree builds, e.g.:
>
> ;;; Generated autoloads from play/5x5.el
>
> But after 43b0210f83c, in my out-of-tree builds, they now look like
> this:
>
> ;;; Generated autoloads from ../../../../../../home/steve/src/emacs/test-29/lisp/play/5x5.el
Isn't the above difference the root cause, right there? Why should
the output in loaddefs.el depend on whether this is an in-tree or
out-of-tree build? Eventually, when the produced loaddefs.el is
installed, the *.el files from the tree and the *.elc files from both
the tree and out-of-tree will end up in the same directory, so there
should be no ../../../.. etc. in the file names recorded in
loaddefs.el, they should be all relative to <source-directory>/lisp,
no? It seems like loaddefs-gen.el does this instead:
(let* ((relfile (file-relative-name
(cadar section)
(file-name-directory loaddefs-file)))
(head (concat "\n\f\n;;; Generated autoloads from "
relfile "\n\n")))
which uses the wrong directory as the second arg of
file-relative-name.
Am I missing something?
Or maybe step through the code in autoloads.el and see how it succeeds
in computing the correct relative file name even in out-of-tree
builds, and let's take it from there.
> I traced the problematic appearance of links in *Help* through the call
> chain describe-function -> describe-function-1 ->
> help-fns-function-description-header -> find-lisp-object-file-name ->
> symbol-file, and symbol-file gets the file name from load-history. In a
> fresh Emacs, started with a triggering init file, load-history contains
> only standard absolute file names, but when I type `C-h f' and then
> evaluate load-history again, it now contains problematic files names
> like "/../home/steve/src/emacs/test-29/lisp/help-fns.elc". I set a
> breakpoint in gdb on build_load_history, but when I hit it after typing
> `C-h f' and started stepping through the function, the first opportunity
> I had to evaluate its argument `filename' already showed the problematic
> form. Then I set a breakpoint on readevalloop, the caller of
> build_load_history in lread.c, but again, the first opportunity I had to
> evaluate readevalloop's argument `sourcename', which is passed to
> build_load_history, already showed the problematic form. I don't know
> where else to look to try and find out how such forms get into
> load-history.
It is possible that these are computed by temacs as part of the build,
so the dumped Emacs gets them already cooked.
However, I think we should concentrate on the first place with the
deviation, which I think is loaddefs.el.
bug-gnu-emacs@HIDDEN:bug#62099; Package emacs.
Full text available.
Received: (at 62099) by debbugs.gnu.org; 14 May 2023 16:19:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 14 12:19:10 2023
Received: from localhost ([127.0.0.1]:41364 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1pyERB-0007xx-RC
for submit <at> debbugs.gnu.org; Sun, 14 May 2023 12:19:10 -0400
Received: from mout.gmx.net ([212.227.17.21]:33103)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <stephen.berman@HIDDEN>) id 1pyER8-0007xV-TB
for 62099 <at> debbugs.gnu.org; Sun, 14 May 2023 12:19:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417;
t=1684081140; i=stephen.berman@HIDDEN;
bh=7rlnZYfRm/P1t8MzjZHtTU8scdDKdFiSA869MvdGiHY=;
h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date;
b=snDiGPPlvzg9MOJmtau5t+Ao/Fvxh2NQqz0LN9x7uoa4feUvkfGUn0Z6lfIa5Eh9p
2zMIeidCYhf5bNV9uYzdas3AKMFsx9KBHBTIUNa9NtnTmACLjbeRpxs56T/Zhz2qup
TX/0nDoL/aqu7Y56fai+Zr6ji1aI5x7FqEQ/Mcy9KRrqUqGRUTLZuyaBVg4TiiVvjJ
PVIpJQq5H4UJ7QVKUCxXKHYzu+cApp/dNujt05p3FLvOKz/f87G9Qn2aO54zF5pCNm
8+aj87sELg2Nm57sPo2xBCiyLWJDfYRPeInynLr3ENlMfSxyUREh7IZS+MjfqU+u72
1dVg70T4xyXpA==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from strobelfs ([94.134.196.122]) by mail.gmx.net (mrgmx104
[212.227.17.168]) with ESMTPSA (Nemesis) id 1Mplbx-1qWEnJ2mnl-00qAft; Sun, 14
May 2023 18:19:00 +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: <83o7mq3xnp.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 12 May
2023 08:51:22 +0300")
References: <87pm9gv8fa.fsf@HIDDEN> <83sfebwkqv.fsf@HIDDEN>
<87edpvihw5.fsf@HIDDEN> <87ednmmuyq.fsf@HIDDEN>
<83o7mq3xnp.fsf@HIDDEN>
Date: Sun, 14 May 2023 18:18:59 +0200
Message-ID: <87353yc2do.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:tBVBVnZG1MsXP1BIKDfwrQTNrua14xVF+553gF+IOQRKa5jl6xh
3V800hER5HR+6fkNZxkNe2Fbny+TTV22gg40glAiRUd6AY13g0W8RSIK1H+tdZYNiD13uCO
1m/LeA5Q2dIj4pOcE+Xu/M5SxvgyNWhKCmOEBQIE7uG/23Kjvn5cqZ9R+MWdc0dTvNfYv2A
uBgVdinkyukX8LmqZE5qg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:3HQyPXny5F4=;KUWAESOoS6LoyfDgQ/39SZjWSFG
o3y3ltxEDI6t3wMrrnU5sO7ZXw8x0CVLIBikrDp/PZBG2wGxSz1knvkaplFA7QRlQbXzgQhwe
3xqPNgt81+Hh43cxebMG06Iyuuc/A+VdYFsIVrTyMXzwTIUbplBg8XbYfbtOmyvPwBInPJXJH
/ly72F8hlLdK7UnfSfDPgY071CGrjMYdX/is/B/X2uo5HnCoLMKCxAv2NBvonh+AjrlQJmYj/
cRUAfjmMpQVtJDXrrnSHnIFATr9Turj2H3ZhyebG1GXS3kP4tgEM3tRBUNc/LuOqDRJMBqKWd
DzOK+eM1clG44V2coCVkRAQLuqAU63OJQeGdQN1LeuHnEe0xkkPYpMyxzjKN7NMg8tyi3c2Sd
Cx82aUTiCAH9gikpxXSM4v4ufZ3AD7YMFMkMnEOp1kk1PMzFVrzS5TYUKExKDTUIFyZa0oYp+
ohj2OMRvWYWdcnqmKklnsQ3IwlxGCtiLCDUAeCBK9gs6cDpdi0uQaz1s+3O28/hFEvhk8QWKb
ArknilImBX5G4X9z7z4B2UMkb1tVclW+rzveRyAYtMtGcLoZD2XcIbahhcnS4Lhat3tSzJNqV
V0Y2v36DK2v6FVEFEvOqN/zRRK95Jz/CTxAhqpcqO5cqAvCv0lR/N9KH2X9KxxXk7EO0xZudF
wxmJWE6EXV3YfeXRrkWJs0VXHGZkSNrCdNrjJHUSpR9wG92niPubee7CbNfOX55AUmkC0PEio
nlLlezg9EoJCz8fATmrEGiOiX8yZrmsYgOdRpDYY2GTK9KaZ5MO/JAmzs7HVyBVTr+34CVthe
UN43wSeadeKqVboouLRdMZAoWfgvw5+GmGEd/wfKpa+2jquNkLM2XSpoYrh4t5wnTvpVj08pL
tg66dnXre04tizClcQ8yN5hVLTCucTA5S7lpHTovOBgfJIZZFR1xxs46qU9sDl/OaiMoWFV7c
i0CnukAUE5fhMyhq1ugL1zZTaW0=
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 62099
Cc: 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 Fri, 12 May 2023 08:51:22 +0300 Eli Zaretskii <eliz@HIDDEN> wrote:
>> From: Stephen Berman <stephen.berman@HIDDEN>
>> Cc: 62099 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi@HIDDEN>
>> Date: Thu, 11 May 2023 23:14:37 +0200
>>
>> 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 determin=
e
>> what part of the change in 43b0210f83c causes this issue.
>
> Well, if you could find out the offending code, it will be
> appreciated.
43b0210f83c only changed how loaddefs.el is generated, and for
out-of-tree builds, also how the names of the files under lisp are
represented in loaddefs.el. Prior to the change, in out-of-tree builds
these file names appeared the same as those in in-tree builds, e.g.:
;;; Generated autoloads from play/5x5.el
But after 43b0210f83c, in my out-of-tree builds, they now look like
this:
;;; Generated autoloads from ../../../../../../home/steve/src/emacs/test-2=
9/lisp/play/5x5.el
What I guess happens is that some code (but which? I haven't found it)
truncates such file names to produce standard absolute file names, which
are then further truncated by help-fns-short-filename to produce the
links in *Help* buffers. If this is right, then it works with -Q, but
when the init file adds a file or directory under ~/.emacs.d to
load-path, this somehow breaks the truncation, so
help-fns-short-filename fails to produce the desired link appearance.
But I have no idea how this breakage happens and why that initialization
triggers it.
I traced the problematic appearance of links in *Help* through the call
chain describe-function -> describe-function-1 ->
help-fns-function-description-header -> find-lisp-object-file-name ->
symbol-file, and symbol-file gets the file name from load-history. In a
fresh Emacs, started with a triggering init file, load-history contains
only standard absolute file names, but when I type `C-h f' and then
evaluate load-history again, it now contains problematic files names
like "/../home/steve/src/emacs/test-29/lisp/help-fns.elc". I set a
breakpoint in gdb on build_load_history, but when I hit it after typing
`C-h f' and started stepping through the function, the first opportunity
I had to evaluate its argument `filename' already showed the problematic
form. Then I set a breakpoint on readevalloop, the caller of
build_load_history in lread.c, but again, the first opportunity I had to
evaluate readevalloop's argument `sourcename', which is passed to
build_load_history, already showed the problematic form. I don't know
where else to look to try and find out how such forms get into
load-history.
If the reason for the aberrant file names in load-history can't be
found, or if avoiding them has more serious disadvantageous, I see two
alternatives: one is to do nothing, since this is apparently only a
cosmetic bug and there's an easy way to avoid triggering it, namely, by
not adding files under ~/.emacs.d to load-path, for which it suffices to
leave such files where they are and just symlink them to a location
outside of ~/.emacs.d and add that location to load-path; that's what
I've currently done in my init. Or as a workaround fix in Emacs,
adjusting help-fns-short-filename as follows seems to do the trick, and
AFAICT has no unwanted side-effects:
diff --git a/lisp/help-fns.el b/lisp/help-fns.el
index 1966193d1a7..9204f45210c 100644
=2D-- a/lisp/help-fns.el
+++ b/lisp/help-fns.el
@@ -954,7 +954,10 @@ help-fns--mention-shortdoc-groups
(goto-char (point-max))))))
(defun help-fns-short-filename (filename)
- (let* ((abbrev (abbreviate-file-name filename))
+ (let* ((filename (if (string-match "^/\\.\\." filename)
+ (substring filename 3)
+ filename))
+ (abbrev (abbreviate-file-name filename))
(short abbrev))
(dolist (dir load-path)
(let ((rel (file-relative-name filename dir)))
(This could, of course, also be used as advice in the init file, as
another alternative for individual users.)
Steve Berman
bug-gnu-emacs@HIDDEN:bug#62099; Package emacs.
Full text available.Received: (at 62099) by debbugs.gnu.org; 12 May 2023 05:50:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 12 01:50:24 2023 Received: from localhost ([127.0.0.1]:53805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1pxLfb-00069e-Pr for submit <at> debbugs.gnu.org; Fri, 12 May 2023 01:50:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1pxLfZ-00069K-6Y for 62099 <at> debbugs.gnu.org; Fri, 12 May 2023 01:50:21 -0400 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 1pxLfS-00066J-GC; Fri, 12 May 2023 01:50:14 -0400 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=HvaVSD5M0mx7e/RoxV3AtUDIV0mCDQv+3Fwnq0fhVyU=; b=Lu5ouv0b5Zo1 7EwugpWuKkXWaRamQ1GTyhOPzRJEI4Iz+px6Uop6ZjBGwuZZ9VWWvmYc786ROI6PUeCtzbGGvTREo uJzB2dPyRkF1SaDb/+pG6skxFm3ICqsu98HqV31fulNhZuxWtJISp8LR/lfyiEXxCVsY93GX1OEad PGZX7vPPVRKJyt15kOHqSJnEqJo2xdn6EVHw8S/Eld8QK9XJaRCObb1mbKpjBr9CYUQ1DkPXl/7Wh GD0C8eGIiQEV4W+N5GhN1y1LqZDAfrxULCS8JLvEzL9f1Y7h/3u/QhBzDRfujJgNlg6qf0Qgdqg0t 7X7Dd2lyTZ4QhO942RggWw==; 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 1pxLfQ-0003jq-VT; Fri, 12 May 2023 01:50:13 -0400 Date: Fri, 12 May 2023 08:51:22 +0300 Message-Id: <83o7mq3xnp.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stephen Berman <stephen.berman@HIDDEN> In-Reply-To: <87ednmmuyq.fsf@HIDDEN> (message from Stephen Berman on Thu, 11 May 2023 23:14:37 +0200) Subject: Re: bug#62099: 29.0.60; Intentional change to *Help* source code links? References: <87pm9gv8fa.fsf@HIDDEN> <83sfebwkqv.fsf@HIDDEN> <87edpvihw5.fsf@HIDDEN> <87ednmmuyq.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62099 Cc: 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: -3.3 (---) > From: Stephen Berman <stephen.berman@HIDDEN> > Cc: 62099 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi@HIDDEN> > Date: Thu, 11 May 2023 23:14:37 +0200 > > 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. Well, if you could find out the offending code, it will be appreciated. Thanks.
bug-gnu-emacs@HIDDEN:bug#62099; Package emacs.
Full text available.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.