Lars Ingebrigtsen <larsi@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 44494) by debbugs.gnu.org; 7 Nov 2020 16:10:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 07 11:10:09 2020 Received: from localhost ([127.0.0.1]:59143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1kbQn2-0001Za-TT for submit <at> debbugs.gnu.org; Sat, 07 Nov 2020 11:10:09 -0500 Received: from mail-lf1-f44.google.com ([209.85.167.44]:33372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <prouleau001@HIDDEN>) id 1kbQn0-0001Yp-Qe for 44494 <at> debbugs.gnu.org; Sat, 07 Nov 2020 11:10:07 -0500 Received: by mail-lf1-f44.google.com with SMTP id l2so6233264lfk.0 for <44494 <at> debbugs.gnu.org>; Sat, 07 Nov 2020 08:10:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l82kqRh37R1cxHSRT/Ulipq8A0ZWUXS5tc/XnWCykns=; b=T6D/DEA1sTPqORP8dZU/jSuVdHkxnDJeXNR78VaKdyID1DSbzD5XvjzwXi6ms/Zq2G +yUqhB5LcomSfrFQBIVo0hzhK4BYZpJ4lIxqJp8bw4SmL6kZRgm6k3AP8GW3+6VvS/3i MBxhsjD/5zlkbXyleVSnitIqnSxTBNshGFdxbRVCqizEKr3BPMoUaWJ6d99PK+H1dZAl xNNmvcW8IGoI0WlllscGVoeCRi7b2bBxAy2dwNhqzy1L1ifLiE7K1jKDl0HzrtIZSjlf cMdEa5jE3dvSdZJ9bxe0UBWZ7YRpwrwzNHitdMXzOJSUmnBJp3Rd8S+XUYZwaDCnjUQZ LJTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l82kqRh37R1cxHSRT/Ulipq8A0ZWUXS5tc/XnWCykns=; b=PvUdst++4vZrDZLMmGBPx01duAnXywAln+g4mUwiVViv0Wi6j/vcGFdIVTgG3Bg9tl o0RmFDzykKomTBDaPF54zYhVAYmDqGF6TdPrpQCQRwL4zqJVRAN/Kr8cgUSffWXeeoMR 94fw0YVSUAAQIaUYINLyDM8sV/nabW2ammzEaqdpCY82KyWINRUCCYBDDQoLoNuyP2Uf 5VAzN0rt3kxibvQYqOH0EDeat4F8oRKcdIhY8EHLe7oephd7akdNrvqg2j8CYz0DSC0t Ld4Re+fP3MORSPcvNd3lgaJrTC+A8Ry8L6C1EInic84JK6uYrleL5XSh6dZcwgeClSOo RF8A== X-Gm-Message-State: AOAM5319eg+Z0jxG0qW5TiroSvbvf/SZuB4TsuUe9I9sziaUYNfJQ/XF kaU7NRYJSp7PyiDFG6PN4ZIiFqmTDtowOe9GiBQ= X-Google-Smtp-Source: ABdhPJyiMwpQqIKOMrDA9gKH/r5ZUTiKyOVCPYNRE+MqrRykb2V7eWNzxWzbPm3gaRyvy1woQZkpJnO0LP9BdGauS58= X-Received: by 2002:ac2:555e:: with SMTP id l30mr1703477lfk.303.1604765400887; Sat, 07 Nov 2020 08:10:00 -0800 (PST) MIME-Version: 1.0 References: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN> <1cdac9f7-8340-83eb-f619-583e028e6e23@HIDDEN> <CALTqLiZtHEjtHB7BGKuFknKDLgNvpbjDkfNhoK9pLFi7k2LYxQ@HIDDEN> <83wnyx7g0u.fsf@HIDDEN> <CALTqLiZuDKW3QJhfqEaK=J4aqJ_qAh-TTpB19sf0jg=d+w=bwA@HIDDEN> <838sbd6xn1.fsf@HIDDEN> <CALTqLiZPARMx9OtenbBJ1GG3ie=BC=-n3u1H-7=BK5ZX4xDLcQ@HIDDEN> <CALTqLiYYn0+RsNRpke7u3X0OaaE1w+rTDdEccHqERcU=97o4vA@HIDDEN> <834km16u5w.fsf@HIDDEN> In-Reply-To: <834km16u5w.fsf@HIDDEN> From: Pierre Rouleau <prouleau001@HIDDEN> Date: Sat, 7 Nov 2020 11:09:49 -0500 Message-ID: <CALTqLiZ9EAYJGudZzQ3p-4zB9kdPEU+cYrY0J6SM1Bd2YRmFxw@HIDDEN> Subject: Re: bug#44494: etags.el xref-location-marker does not handle TAGS references to .el.gz files To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000aaf4eb05b3868f54" X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Sat, Nov 7, 2020 at 10:52 AM Eli Zaretskii wrote: > > From: Pierre Rouleau > > Date: Sat, 7 Nov 2020 10:39:41 -0500 > > Cc: dgutov@HIDDEN, 44494 <at> debbugs.gnu.org > > > > One difference is that when using find-tag is using code from etags.el > exc [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (prouleau001[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (prouleau001[at]gmail.com) -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.44 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.44 listed in list.dnswl.org] 0.0 HTML_MESSAGE BODY: HTML included in message 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: 44494 Cc: 44494 <at> debbugs.gnu.org, dgutov@HIDDEN 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: -0.7 (/) --000000000000aaf4eb05b3868f54 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 7, 2020 at 10:52 AM Eli Zaretskii <eliz@HIDDEN> wrote: > > From: Pierre Rouleau <prouleau001@HIDDEN> > > Date: Sat, 7 Nov 2020 10:39:41 -0500 > > Cc: dgutov@HIDDEN, 44494 <at> debbugs.gnu.org > > > > One difference is that when using find-tag is using code from etags.el > exclusively: > > - find-tag-noselect > > . - find-tag-in-order , which tries different predicates and the one > that succeeds is > > tag-implicit-name-match-p > > . - it identifies the cc-bytecomp.el.gz > > .- calls etags-goto-tag-location > > The Xref etags backend also uses tag-implicit-name-match-p: > > (defvar etags-xref-find-definitions-tag-order '(tag-exact-match-p > > tag-implicit-name-match-p) > "Tag order used in `xref-backend-definitions' to look for definitions. > > If you want `xref-find-definitions' to find the tagged files by their > file name, add `tag-partial-file-name-match-p' to the list value.") > > > When using xref-find-definition the xref backend is used. It's not the > same code. > > The xref backend code for elisp does not find it. The backend code for > etags does not find it either. > > It tries to open cc-bytecomp.el as its the file name it gets from the > TAGS file. > > It detects the file not being present and reports it as missing, > assuming the file have been removed. > > > > To me the 2 sets of code look very different. > > They share some of the code, at least when xref-etags-mode is used. > So it sounds like some information found by tag-implicit-name-match-p > doesn't get handed back to Xref? > > For the Xref's own ELisp backend, we will probably need to code > something in xref.el. > Sorry, I meant that find-tag-in-order is able to find the reference in the TAGS file when it tries the tag-implicit-name-match-p predicate. find-tag-in-order returns a marker that identifies the .el.gz file. I agree that for the ELisp backend something probably needs to be done to support it. But I also think that something must also be done for the etags xref backend. -- /Pierre --000000000000aaf4eb05b3868f54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div dir=3D"ltr"></div><br><div class=3D"gmail_quote"= ><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Nov 7, 2020 at 10:52 AM Eli = Zaretskii <<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN</a>> wrote:<b= r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex= ;border-left:1px solid rgb(204,204,204);padding-left:1ex">> From: Pierre= Rouleau <<a href=3D"mailto:prouleau001@HIDDEN" target=3D"_blank">pro= uleau001@HIDDEN</a>><br> > Date: Sat, 7 Nov 2020 10:39:41 -0500<br> > Cc: <a href=3D"mailto:dgutov@HIDDEN" target=3D"_blank">dgutov@yande= x.ru</a>, <a href=3D"mailto:44494 <at> debbugs.gnu.org" target=3D"_blank">44494@= debbugs.gnu.org</a><br> > <br> > One difference is that when using find-tag is using code from etags.el= exclusively:<br> > - find-tag-noselect<br> > . - find-tag-in-order=C2=A0 =C2=A0, which tries different predicates a= nd the one that succeeds is<br> > tag-implicit-name-match-p <br> > .=C2=A0 - it identifies the cc-bytecomp.el.gz <br> > .- calls etags-goto-tag-location<br> <br> The Xref etags backend also uses tag-implicit-name-match-p:<br> <br> =C2=A0 (defvar etags-xref-find-definitions-tag-order '(tag-exact-match-= p<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 tag-implicit-name-match-p)<br> =C2=A0 =C2=A0 "Tag order used in `xref-backend-definitions' to loo= k for definitions.<br> <br> =C2=A0 If you want `xref-find-definitions' to find the tagged files by = their<br> =C2=A0 file name, add `tag-partial-file-name-match-p' to the list value= .")<br> <br> > When using xref-find-definition the xref backend is used.=C2=A0 It'= ;s not the same code.=C2=A0 <br> > The xref backend code for elisp does not find it.=C2=A0 The backend co= de for etags does not find it either.<br> > It tries to open cc-bytecomp.el as its the file name it gets from the = TAGS file.<br> > It detects the file not being present and reports it as missing, assum= ing the file have been removed.<br> > <br> > To me the 2 sets of code look very different.<br> <br> They share some of the code, at least when xref-etags-mode is used.<br> So it sounds like some information found by tag-implicit-name-match-p<br> doesn't get handed back to Xref?<br> <br> For the Xref's own ELisp backend, we will probably need to code<br> something in xref.el.<br> </blockquote></div><br clear=3D"all"></div><div>Sorry, I meant that find-ta= g-in-order is able to find the reference in the TAGS file when <br></div><d= iv>it tries the tag-implicit-name-match-p predicate.=C2=A0 find-tag-in-orde= r returns a marker that identifies the .el.gz file.</div><div><br></div><di= v>I agree that for the ELisp backend something probably needs to be done to= support it.=C2=A0 <br></div><div>But I also think that something must also= be done for the etags xref backend.<br></div><div>-- <br><div dir=3D"ltr" = class=3D"gmail_signature">/Pierre</div></div></div> --000000000000aaf4eb05b3868f54--
bug-gnu-emacs@HIDDEN:bug#44494; Package emacs.
Full text available.
Received: (at 44494) by debbugs.gnu.org; 7 Nov 2020 15:52:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 07 10:52:51 2020
Received: from localhost ([127.0.0.1]:59129 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1kbQWI-00017X-Qj
for submit <at> debbugs.gnu.org; Sat, 07 Nov 2020 10:52:51 -0500
Received: from eggs.gnu.org ([209.51.188.92]:51874)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1kbQWG-00017K-2g
for 44494 <at> debbugs.gnu.org; Sat, 07 Nov 2020 10:52:49 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:60249)
by eggs.gnu.org with esmtp (Exim 4.90_1)
(envelope-from <eliz@HIDDEN>)
id 1kbQWA-00086Y-LH; Sat, 07 Nov 2020 10:52:42 -0500
Received: from [176.228.60.248] (port=1594 helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
(Exim 4.82) (envelope-from <eliz@HIDDEN>)
id 1kbQW9-00071X-VX; Sat, 07 Nov 2020 10:52:42 -0500
Date: Sat, 07 Nov 2020 17:52:43 +0200
Message-Id: <834km16u5w.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pierre Rouleau <prouleau001@HIDDEN>
In-Reply-To: <CALTqLiYYn0+RsNRpke7u3X0OaaE1w+rTDdEccHqERcU=97o4vA@HIDDEN>
(message from Pierre Rouleau on Sat, 7 Nov 2020 10:39:41 -0500)
Subject: Re: bug#44494: etags.el xref-location-marker does not handle TAGS
references to .el.gz files
References: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN>
<1cdac9f7-8340-83eb-f619-583e028e6e23@HIDDEN>
<CALTqLiZtHEjtHB7BGKuFknKDLgNvpbjDkfNhoK9pLFi7k2LYxQ@HIDDEN>
<83wnyx7g0u.fsf@HIDDEN>
<CALTqLiZuDKW3QJhfqEaK=J4aqJ_qAh-TTpB19sf0jg=d+w=bwA@HIDDEN>
<838sbd6xn1.fsf@HIDDEN>
<CALTqLiZPARMx9OtenbBJ1GG3ie=BC=-n3u1H-7=BK5ZX4xDLcQ@HIDDEN>
<CALTqLiYYn0+RsNRpke7u3X0OaaE1w+rTDdEccHqERcU=97o4vA@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 44494
Cc: 44494 <at> debbugs.gnu.org, dgutov@HIDDEN
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: Pierre Rouleau <prouleau001@HIDDEN>
> Date: Sat, 7 Nov 2020 10:39:41 -0500
> Cc: dgutov@HIDDEN, 44494 <at> debbugs.gnu.org
>
> One difference is that when using find-tag is using code from etags.el exclusively:
> - find-tag-noselect
> . - find-tag-in-order , which tries different predicates and the one that succeeds is
> tag-implicit-name-match-p
> . - it identifies the cc-bytecomp.el.gz
> .- calls etags-goto-tag-location
The Xref etags backend also uses tag-implicit-name-match-p:
(defvar etags-xref-find-definitions-tag-order '(tag-exact-match-p
tag-implicit-name-match-p)
"Tag order used in `xref-backend-definitions' to look for definitions.
If you want `xref-find-definitions' to find the tagged files by their
file name, add `tag-partial-file-name-match-p' to the list value.")
> When using xref-find-definition the xref backend is used. It's not the same code.
> The xref backend code for elisp does not find it. The backend code for etags does not find it either.
> It tries to open cc-bytecomp.el as its the file name it gets from the TAGS file.
> It detects the file not being present and reports it as missing, assuming the file have been removed.
>
> To me the 2 sets of code look very different.
They share some of the code, at least when xref-etags-mode is used.
So it sounds like some information found by tag-implicit-name-match-p
doesn't get handed back to Xref?
For the Xref's own ELisp backend, we will probably need to code
something in xref.el.
bug-gnu-emacs@HIDDEN:bug#44494; Package emacs.
Full text available.Received: (at 44494) by debbugs.gnu.org; 7 Nov 2020 15:40:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 07 10:40:00 2020 Received: from localhost ([127.0.0.1]:59125 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1kbQJs-0000oK-EJ for submit <at> debbugs.gnu.org; Sat, 07 Nov 2020 10:40:00 -0500 Received: from mail-lf1-f51.google.com ([209.85.167.51]:34095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <prouleau001@HIDDEN>) id 1kbQJq-0000o8-UE for 44494 <at> debbugs.gnu.org; Sat, 07 Nov 2020 10:39:59 -0500 Received: by mail-lf1-f51.google.com with SMTP id i6so6153062lfd.1 for <44494 <at> debbugs.gnu.org>; Sat, 07 Nov 2020 07:39:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R7G/H9kkaCPgf9omo5gJX9tzyTuH6h0QN9DrKmiq5TM=; b=gqNbyJU1SwyyNX+SsmgoTRjHipeX7CDwIbFvQXGmZzGaknOaDgQpkeja16tWvP3wnN 3KYXffFO5fkyOlMbIb/vjSWOzmGLoHtdlFovRAnYrPeCTKztWbgA7dZqU9rIBGnCvo1f yxDCXzgdUQfvBBFCLnIrwdxODP2H4VabV8Ud2v47pqgsfbyBYJDAIFAAPkv8h7i71V8o WPl6TG9UUDtpgqPVg5YKnVBUdMJRPMxxiJtoip4HUr1tm1hLx1/RGnuzwSgQxPf3DeLy 6ErQ9zCEjkigffvBDmZr9K5gk+ugwERLDfy9/+tvKG/EgBZRLo+Ywr6mwsWTkEqbOgfF EoKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R7G/H9kkaCPgf9omo5gJX9tzyTuH6h0QN9DrKmiq5TM=; b=MTlSyuy2FUflEAz+ZoztdLVU3EUJ0NEgJkdK6VfzfkJxbpPmShSl0eDZAaiMqhFJJv sBlWVD/E+92bVDwj6GKpiAj7kzHY6sPlvgKMVO0yXop6Me8rldUqFPo4uCY+E65qHLtD FCBnDfUUP5KzUGWMQkig+mE8L2TfMmQSsi9yJZADbBvQmP0VoYbMIj6QzsFLckrQ5lf2 P+RwAEqLIB5HOmbqkgMK26f3Pct6W9/DZmxCHK3PKDbbF6PiGiFBEFts7MXueG389ocl SYwjH2gIo8a0v6XJZP+pTtNBfxJC3y3rwnQRTVblafPA30qDBInwqM6qy5RP1QTjvzbE x6sg== X-Gm-Message-State: AOAM531Dsw0GBMM7k6Nw5fP7LLpDQoEYHqUUz0rkwRFQrZ0e1nGrtr+W qEG1+K0f5pSTzXX0lzn+bTdPQ11B6GRPCVanQzo= X-Google-Smtp-Source: ABdhPJxDy5eECXutfNAiobQryJn2Ttluz9pX8cAdABsTHdSuocILYuINc8SfWlGA0ZU4813striOxtsdDCfe46kQuEI= X-Received: by 2002:a19:686:: with SMTP id 128mr1517103lfg.198.1604763592878; Sat, 07 Nov 2020 07:39:52 -0800 (PST) MIME-Version: 1.0 References: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN> <1cdac9f7-8340-83eb-f619-583e028e6e23@HIDDEN> <CALTqLiZtHEjtHB7BGKuFknKDLgNvpbjDkfNhoK9pLFi7k2LYxQ@HIDDEN> <83wnyx7g0u.fsf@HIDDEN> <CALTqLiZuDKW3QJhfqEaK=J4aqJ_qAh-TTpB19sf0jg=d+w=bwA@HIDDEN> <838sbd6xn1.fsf@HIDDEN> <CALTqLiZPARMx9OtenbBJ1GG3ie=BC=-n3u1H-7=BK5ZX4xDLcQ@HIDDEN> In-Reply-To: <CALTqLiZPARMx9OtenbBJ1GG3ie=BC=-n3u1H-7=BK5ZX4xDLcQ@HIDDEN> From: Pierre Rouleau <prouleau001@HIDDEN> Date: Sat, 7 Nov 2020 10:39:41 -0500 Message-ID: <CALTqLiYYn0+RsNRpke7u3X0OaaE1w+rTDdEccHqERcU=97o4vA@HIDDEN> Subject: Re: bug#44494: etags.el xref-location-marker does not handle TAGS references to .el.gz files To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000e6f07905b3862342" X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Sat, Nov 7, 2020 at 9:48 AM Pierre Rouleau wrote: > On Sat, Nov 7, 2020 at 9:37 AM Eli Zaretskii wrote: > >> > From: Pierre Rouleau >> > Date: Sat, 7 Nov 2020 09:15:12 -0500 >> > Cc: dgutov@HIDDEN, 44494 <at> debbugs.gnu.org >> > >> > To recap you [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (prouleau001[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (prouleau001[at]gmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.51 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.51 listed in wl.mailspike.net] 0.0 HTML_MESSAGE BODY: HTML included in message 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: 44494 Cc: 44494 <at> debbugs.gnu.org, dgutov@HIDDEN 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: -0.7 (/) --000000000000e6f07905b3862342 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 7, 2020 at 9:48 AM Pierre Rouleau <prouleau001@HIDDEN> wrote= : > On Sat, Nov 7, 2020 at 9:37 AM Eli Zaretskii <eliz@HIDDEN> wrote: > >> > From: Pierre Rouleau <prouleau001@HIDDEN> >> > Date: Sat, 7 Nov 2020 09:15:12 -0500 >> > Cc: dgutov@HIDDEN, 44494 <at> debbugs.gnu.org >> > >> > To recap you need to try searching for something that is not already >> > loaded and use the etags xref backend with a file that contains the >> definition >> > of what one is searching and that is located inside a compressed file. >> >> OK, I've now tried this with paren.el, which is not loaded in "emacs >> -Q". I can confirm that M-. fails to find functions in paren.el (I >> tried show-paren-function, FTR), even if I use xref-etags-mode, but >> "M-x find-tag" succeeds. >> >> So I think we should try to understand why find-tag does work in this >> case, and see how to make xref-find-definitions do the same. Could >> you perhaps do that? >> >> > . emacs -Q >> > . C-x C-f lisp/simple.el.gz >> > . M-x xref-etags-mode >> > . C-u M-x cc-require >> > emacs=3D=3D> prompts Visit tags table (default TAGS): .... >> > me =3D=3D=3D=3D> I select the TAGS file where all definitions are stor= ed and >> hit RET >> > - emacs 26.3 =3D=3D> Rerun etags: =E2=80=98^(defmacro cc-require =E2= =80=99 not found in >> > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmod\ >> > es/cc-bytecomp.el >> > - emacs 27.1 =3D=3D> Rerun etags: =E2=80=98^(defmacro cc-require =E2= =80=99 not found in >> > >> /usr/local/Cellar/emacs/27.1/share/emacs/27.1/lisp/progmodes/cc-bytecomp= .el >> >> Note that at this point, you have an empty cc-bytecomp.el buffer. >> Which I think gives a clue as to where the problem lies. >> > > You are correct, I tried it with find-tag in emacs 26.3 and 27.1 and > find-tag cc-require > does find it, even with the xref-backend-functions set to its default of > (elisp--xref-backend t). > > It fails with xref-find-definitions but works with find-tag. > > I agree there's a need to see what differs there. > > Thanks > > -- > /Pierre > One difference is that when using find-tag is using code from etags.el exclusively: - find-tag-noselect . - find-tag-in-order , which tries different predicates and the one that succeeds is tag-implicit-name-match-p . - it identifies the cc-bytecomp.el.gz .- calls etags-goto-tag-location When using xref-find-definition the xref backend is used. It's not the same code. The xref backend code for elisp does not find it. The backend code for etags does not find it either. It tries to open cc-bytecomp.el as its the file name it gets from the TAGS file. It detects the file not being present and reports it as missing, assuming the file have been removed. To me the 2 sets of code look very different. --=20 /Pierre --000000000000e6f07905b3862342 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g= mail_attr">On Sat, Nov 7, 2020 at 9:48 AM Pierre Rouleau <<a href=3D"mai= lto:prouleau001@HIDDEN">prouleau001@HIDDEN</a>> wrote:<br></div><b= lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div = class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Nov 7, = 2020 at 9:37 AM Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN" target=3D= "_blank">eliz@HIDDEN</a>> wrote:<br></div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= 4);padding-left:1ex">> From: Pierre Rouleau <<a href=3D"mailto:proule= au001@HIDDEN" target=3D"_blank">prouleau001@HIDDEN</a>><br> > Date: Sat, 7 Nov 2020 09:15:12 -0500<br> > Cc: <a href=3D"mailto:dgutov@HIDDEN" target=3D"_blank">dgutov@yande= x.ru</a>, <a href=3D"mailto:44494 <at> debbugs.gnu.org" target=3D"_blank">44494@= debbugs.gnu.org</a><br> > <br> > To recap you need to try searching for something that is not already <= br> > loaded and use the etags xref backend with a file that contains the de= finition<br> > of what one is searching and that is located inside a compressed file.= <br> <br> OK, I've now tried this with paren.el, which is not loaded in "ema= cs<br> -Q".=C2=A0 I can confirm that M-. fails to find functions in paren.el = (I<br> tried show-paren-function, FTR), even if I use xref-etags-mode, but<br> "M-x find-tag" succeeds.<br> <br> So I think we should try to understand why find-tag does work in this<br> case, and see how to make xref-find-definitions do the same.=C2=A0 Could<br= > you perhaps do that?<br> <br> > . emacs -Q<br> > . C-x C-f lisp/simple.el.gz<br> > . M-x xref-etags-mode<br> > . C-u M-x cc-require<br> > emacs=3D=3D> prompts Visit tags table (default TAGS): ....<br> > me =3D=3D=3D=3D> I select the TAGS file where all definitions are s= tored and hit RET<br> > - emacs 26.3 =3D=3D> Rerun etags: =E2=80=98^(defmacro cc-require = =E2=80=99 not found in<br> > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmod\<br> > es/cc-bytecomp.el<br> > - emacs 27.1 =3D=3D> Rerun etags: =E2=80=98^(defmacro cc-require = =E2=80=99 not found in<br> > /usr/local/Cellar/emacs/27.1/share/emacs/27.1/lisp/progmodes/cc-byteco= mp.el<br> <br> Note that at this point, you have an empty cc-bytecomp.el buffer.<br> Which I think gives a clue as to where the problem lies.<br> </blockquote></div><br clear=3D"all"></div><div>You are correct, I tried it= with find-tag in emacs 26.3 and 27.1 and find-tag cc-require <br></div><di= v>does find it, even with the xref-backend-functions set to its default of<= /div><div>(elisp--xref-backend t).</div><div><br></div><div>It fails with x= ref-find-definitions but works with find-tag.</div><div><br></div><div>I ag= ree there's a need to see what differs there.</div><div><br></div><div>= Thanks<br></div><div><br></div><div><div>-- <br><div dir=3D"ltr">/Pierre</d= iv></div></div></div> </blockquote></div><div><br></div><div>One difference is that when using fi= nd-tag is using code from etags.el exclusively:<br></div><div>- find-tag-no= select</div><div>. - find-tag-in-order=C2=A0=C2=A0 , which tries different = predicates and the one that succeeds is tag-implicit-name-match-p <br></div= ><div>.=C2=A0 - it identifies the cc-bytecomp.el.gz=C2=A0</div><div>.- call= s etags-goto-tag-location</div><div><br></div><div>When using xref-find-def= inition the xref backend is used.=C2=A0 It's not the same code.=C2=A0 <= br></div><div>The xref backend code for elisp does not find it.=C2=A0 The b= ackend code for etags does not find it either.</div><div>It tries to open c= c-bytecomp.el as its the file name it gets from the TAGS file.</div><div>It= detects the file not being present and reports it as missing, assuming the= file have been removed.</div><div><br></div><div>To me the 2 sets of code = look very different.<br></div><br>-- <br><div dir=3D"ltr" class=3D"gmail_si= gnature">/Pierre</div></div> --000000000000e6f07905b3862342--
bug-gnu-emacs@HIDDEN:bug#44494; Package emacs.
Full text available.Received: (at 44494) by debbugs.gnu.org; 7 Nov 2020 14:48:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 07 09:48:44 2020 Received: from localhost ([127.0.0.1]:58167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1kbPWG-0007iG-7m for submit <at> debbugs.gnu.org; Sat, 07 Nov 2020 09:48:44 -0500 Received: from mail-lj1-f181.google.com ([209.85.208.181]:38171) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <prouleau001@HIDDEN>) id 1kbPWD-0007i3-Qw for 44494 <at> debbugs.gnu.org; Sat, 07 Nov 2020 09:48:42 -0500 Received: by mail-lj1-f181.google.com with SMTP id v19so4713771lji.5 for <44494 <at> debbugs.gnu.org>; Sat, 07 Nov 2020 06:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LYO2z7fjlHrZcFbsMrKMLSn1Mgr1TEf7JYQO7Yacex0=; b=hxfHRSQWykQzGm8imB505tGasxkkCMt/pdxqzQh22qUVto3E3MFKT8dxgqAdQE+I8k tzrCaBZDQxfqtQYPYe2D47zz2QwiS3eywmaUOljPZ/uk3rpgvaSYy0aNq0CkO9g5f8Th kPLZu/7x+sbyz//5RR51pnVLRBJpzeOY04eZmAdCAV8t4F/3+G8LJ7zdzxomRGPmTCJi krjvv5ir6v6w22CkOeyTRQHp+9DS1OaIi00b0J4G8k1J+ccGySOtusj34/8TKQkwMyDu 9G6sGBb11lyoPly9haRepSRw7Go7Qwoh6ukDVXTGCumHZgbKUUlXAxhiWu/LgHETNdqJ k4Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LYO2z7fjlHrZcFbsMrKMLSn1Mgr1TEf7JYQO7Yacex0=; b=fYRzFsiD5arOK1mJX8gw04jqAuK3/w/RnwX+0hBt6BA2nxId7dgSA09IN2iUS3iehd inutcrD54Ruwxcf159YdE7uFIFb+v4YLUw1NdpKOhkHnDQP/vI29ZMHY2ahn97YA1IAy +/0m+piJnKExzPbKO7M8AnWdYZqCkZRcYPy21s0kQmFmT+QkMQXMdzkaj+S/KtBMoGUr RpNx/rGsLeO71nhgj6buCcBWzSK3CmwMVaBkjtdSe6F6GtaOouaeD/Dktr42781Rq1TX iKbc04fIckpcjZqR7JOHZz/QkFt7nAK+sTXeNONXeh58qsuHf7SJjnZgnuUCkr5QGIL7 VWxQ== X-Gm-Message-State: AOAM530u43JsieV5CBxqI2lGuwUVYv0CTZKK62HDP7wQOfh+rDTbOR8B t/P8Gx2OuKSCyxAAXb860kudMZkOo4EM9r7xKaA= X-Google-Smtp-Source: ABdhPJxpnsL39LjEr7unKg1xBI/CcMkgDy3ppUCfJNEhBuhrxPf5vfAYvkPh3vj5TZ9vNNHlXLFrDqQ/s1uaIH/1rCQ= X-Received: by 2002:a2e:5801:: with SMTP id m1mr880487ljb.320.1604760515683; Sat, 07 Nov 2020 06:48:35 -0800 (PST) MIME-Version: 1.0 References: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN> <1cdac9f7-8340-83eb-f619-583e028e6e23@HIDDEN> <CALTqLiZtHEjtHB7BGKuFknKDLgNvpbjDkfNhoK9pLFi7k2LYxQ@HIDDEN> <83wnyx7g0u.fsf@HIDDEN> <CALTqLiZuDKW3QJhfqEaK=J4aqJ_qAh-TTpB19sf0jg=d+w=bwA@HIDDEN> <838sbd6xn1.fsf@HIDDEN> In-Reply-To: <838sbd6xn1.fsf@HIDDEN> From: Pierre Rouleau <prouleau001@HIDDEN> Date: Sat, 7 Nov 2020 09:48:24 -0500 Message-ID: <CALTqLiZPARMx9OtenbBJ1GG3ie=BC=-n3u1H-7=BK5ZX4xDLcQ@HIDDEN> Subject: Re: bug#44494: etags.el xref-location-marker does not handle TAGS references to .el.gz files To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000007cac5305b3856c17" X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Sat, Nov 7, 2020 at 9:37 AM Eli Zaretskii wrote: > > From: Pierre Rouleau > > Date: Sat, 7 Nov 2020 09:15:12 -0500 > > Cc: dgutov@HIDDEN, 44494 <at> debbugs.gnu.org > > > > To recap you need to try searching for something that is not already > > loa [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (prouleau001[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (prouleau001[at]gmail.com) -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.208.181 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.208.181 listed in list.dnswl.org] 0.0 HTML_MESSAGE BODY: HTML included in message 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: 44494 Cc: 44494 <at> debbugs.gnu.org, dgutov@HIDDEN 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: -0.7 (/) --0000000000007cac5305b3856c17 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 7, 2020 at 9:37 AM Eli Zaretskii <eliz@HIDDEN> wrote: > > From: Pierre Rouleau <prouleau001@HIDDEN> > > Date: Sat, 7 Nov 2020 09:15:12 -0500 > > Cc: dgutov@HIDDEN, 44494 <at> debbugs.gnu.org > > > > To recap you need to try searching for something that is not already > > loaded and use the etags xref backend with a file that contains the > definition > > of what one is searching and that is located inside a compressed file. > > OK, I've now tried this with paren.el, which is not loaded in "emacs > -Q". I can confirm that M-. fails to find functions in paren.el (I > tried show-paren-function, FTR), even if I use xref-etags-mode, but > "M-x find-tag" succeeds. > > So I think we should try to understand why find-tag does work in this > case, and see how to make xref-find-definitions do the same. Could > you perhaps do that? > > > . emacs -Q > > . C-x C-f lisp/simple.el.gz > > . M-x xref-etags-mode > > . C-u M-x cc-require > > emacs=3D=3D> prompts Visit tags table (default TAGS): .... > > me =3D=3D=3D=3D> I select the TAGS file where all definitions are store= d and hit > RET > > - emacs 26.3 =3D=3D> Rerun etags: =E2=80=98^(defmacro cc-require =E2=80= =99 not found in > > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmod\ > > es/cc-bytecomp.el > > - emacs 27.1 =3D=3D> Rerun etags: =E2=80=98^(defmacro cc-require =E2=80= =99 not found in > > > /usr/local/Cellar/emacs/27.1/share/emacs/27.1/lisp/progmodes/cc-bytecomp.= el > > Note that at this point, you have an empty cc-bytecomp.el buffer. > Which I think gives a clue as to where the problem lies. > You are correct, I tried it with find-tag in emacs 26.3 and 27.1 and find-tag cc-require does find it, even with the xref-backend-functions set to its default of (elisp--xref-backend t). It fails with xref-find-definitions but works with find-tag. I agree there's a need to see what differs there. Thanks --=20 /Pierre --0000000000007cac5305b3856c17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"= gmail_attr">On Sat, Nov 7, 2020 at 9:37 AM Eli Zaretskii <<a href=3D"mai= lto:eliz@HIDDEN">eliz@HIDDEN</a>> wrote:<br></div><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2= 04,204,204);padding-left:1ex">> From: Pierre Rouleau <<a href=3D"mail= to:prouleau001@HIDDEN" target=3D"_blank">prouleau001@HIDDEN</a>><b= r> > Date: Sat, 7 Nov 2020 09:15:12 -0500<br> > Cc: <a href=3D"mailto:dgutov@HIDDEN" target=3D"_blank">dgutov@yande= x.ru</a>, <a href=3D"mailto:44494 <at> debbugs.gnu.org" target=3D"_blank">44494@= debbugs.gnu.org</a><br> > <br> > To recap you need to try searching for something that is not already <= br> > loaded and use the etags xref backend with a file that contains the de= finition<br> > of what one is searching and that is located inside a compressed file.= <br> <br> OK, I've now tried this with paren.el, which is not loaded in "ema= cs<br> -Q".=C2=A0 I can confirm that M-. fails to find functions in paren.el = (I<br> tried show-paren-function, FTR), even if I use xref-etags-mode, but<br> "M-x find-tag" succeeds.<br> <br> So I think we should try to understand why find-tag does work in this<br> case, and see how to make xref-find-definitions do the same.=C2=A0 Could<br= > you perhaps do that?<br> <br> > . emacs -Q<br> > . C-x C-f lisp/simple.el.gz<br> > . M-x xref-etags-mode<br> > . C-u M-x cc-require<br> > emacs=3D=3D> prompts Visit tags table (default TAGS): ....<br> > me =3D=3D=3D=3D> I select the TAGS file where all definitions are s= tored and hit RET<br> > - emacs 26.3 =3D=3D> Rerun etags: =E2=80=98^(defmacro cc-require = =E2=80=99 not found in<br> > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmod\<br> > es/cc-bytecomp.el<br> > - emacs 27.1 =3D=3D> Rerun etags: =E2=80=98^(defmacro cc-require = =E2=80=99 not found in<br> > /usr/local/Cellar/emacs/27.1/share/emacs/27.1/lisp/progmodes/cc-byteco= mp.el<br> <br> Note that at this point, you have an empty cc-bytecomp.el buffer.<br> Which I think gives a clue as to where the problem lies.<br> </blockquote></div><br clear=3D"all"></div><div>You are correct, I tried it= with find-tag in emacs 26.3 and 27.1 and find-tag cc-require <br></div><di= v>does find it, even with the xref-backend-functions set to its default of<= /div><div>(elisp--xref-backend t).</div><div><br></div><div>It fails with x= ref-find-definitions but works with find-tag.</div><div><br></div><div>I ag= ree there's a need to see what differs there.</div><div><br></div><div>= Thanks<br></div><div><br></div><div><div>-- <br><div dir=3D"ltr" class=3D"g= mail_signature">/Pierre</div></div></div></div> --0000000000007cac5305b3856c17--
bug-gnu-emacs@HIDDEN:bug#44494; Package emacs.
Full text available.Received: (at 44494) by debbugs.gnu.org; 7 Nov 2020 14:37:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 07 09:37:45 2020 Received: from localhost ([127.0.0.1]:58163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1kbPLd-0007RW-4G for submit <at> debbugs.gnu.org; Sat, 07 Nov 2020 09:37:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39974) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1kbPLb-0007RI-7H for 44494 <at> debbugs.gnu.org; Sat, 07 Nov 2020 09:37:43 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59450) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1kbPLV-0006ux-7F; Sat, 07 Nov 2020 09:37:37 -0500 Received: from [176.228.60.248] (port=4917 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1kbPLU-0004Om-Jj; Sat, 07 Nov 2020 09:37:37 -0500 Date: Sat, 07 Nov 2020 16:37:38 +0200 Message-Id: <838sbd6xn1.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pierre Rouleau <prouleau001@HIDDEN> In-Reply-To: <CALTqLiZuDKW3QJhfqEaK=J4aqJ_qAh-TTpB19sf0jg=d+w=bwA@HIDDEN> (message from Pierre Rouleau on Sat, 7 Nov 2020 09:15:12 -0500) Subject: Re: bug#44494: etags.el xref-location-marker does not handle TAGS references to .el.gz files References: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN> <1cdac9f7-8340-83eb-f619-583e028e6e23@HIDDEN> <CALTqLiZtHEjtHB7BGKuFknKDLgNvpbjDkfNhoK9pLFi7k2LYxQ@HIDDEN> <83wnyx7g0u.fsf@HIDDEN> <CALTqLiZuDKW3QJhfqEaK=J4aqJ_qAh-TTpB19sf0jg=d+w=bwA@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44494 Cc: 44494 <at> debbugs.gnu.org, dgutov@HIDDEN 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: Pierre Rouleau <prouleau001@HIDDEN> > Date: Sat, 7 Nov 2020 09:15:12 -0500 > Cc: dgutov@HIDDEN, 44494 <at> debbugs.gnu.org > > To recap you need to try searching for something that is not already > loaded and use the etags xref backend with a file that contains the definition > of what one is searching and that is located inside a compressed file. OK, I've now tried this with paren.el, which is not loaded in "emacs -Q". I can confirm that M-. fails to find functions in paren.el (I tried show-paren-function, FTR), even if I use xref-etags-mode, but "M-x find-tag" succeeds. So I think we should try to understand why find-tag does work in this case, and see how to make xref-find-definitions do the same. Could you perhaps do that? > . emacs -Q > . C-x C-f lisp/simple.el.gz > . M-x xref-etags-mode > . C-u M-x cc-require > emacs==> prompts Visit tags table (default TAGS): .... > me ====> I select the TAGS file where all definitions are stored and hit RET > - emacs 26.3 ==> Rerun etags: ‘^(defmacro cc-require ’ not found in > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmod\ > es/cc-bytecomp.el > - emacs 27.1 ==> Rerun etags: ‘^(defmacro cc-require ’ not found in > /usr/local/Cellar/emacs/27.1/share/emacs/27.1/lisp/progmodes/cc-bytecomp.el Note that at this point, you have an empty cc-bytecomp.el buffer. Which I think gives a clue as to where the problem lies.
bug-gnu-emacs@HIDDEN:bug#44494; Package emacs.
Full text available.Received: (at 44494) by debbugs.gnu.org; 7 Nov 2020 14:22:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 07 09:22:56 2020 Received: from localhost ([127.0.0.1]:58158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1kbP7H-00076W-Rx for submit <at> debbugs.gnu.org; Sat, 07 Nov 2020 09:22:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38326) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1kbP7F-00076K-Ut for 44494 <at> debbugs.gnu.org; Sat, 07 Nov 2020 09:22:54 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59335) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1kbP7A-0001l2-3H; Sat, 07 Nov 2020 09:22:48 -0500 Received: from [176.228.60.248] (port=4010 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1kbP79-0000bh-FE; Sat, 07 Nov 2020 09:22:47 -0500 Date: Sat, 07 Nov 2020 16:22:48 +0200 Message-Id: <83a6vt6ybr.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pierre Rouleau <prouleau001@HIDDEN> In-Reply-To: <CALTqLiZuDKW3QJhfqEaK=J4aqJ_qAh-TTpB19sf0jg=d+w=bwA@HIDDEN> (message from Pierre Rouleau on Sat, 7 Nov 2020 09:15:12 -0500) Subject: Re: bug#44494: etags.el xref-location-marker does not handle TAGS references to .el.gz files References: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN> <1cdac9f7-8340-83eb-f619-583e028e6e23@HIDDEN> <CALTqLiZtHEjtHB7BGKuFknKDLgNvpbjDkfNhoK9pLFi7k2LYxQ@HIDDEN> <83wnyx7g0u.fsf@HIDDEN> <CALTqLiZuDKW3QJhfqEaK=J4aqJ_qAh-TTpB19sf0jg=d+w=bwA@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44494 Cc: 44494 <at> debbugs.gnu.org, dgutov@HIDDEN 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: Pierre Rouleau <prouleau001@HIDDEN> > Date: Sat, 7 Nov 2020 09:15:12 -0500 > Cc: dgutov@HIDDEN, 44494 <at> debbugs.gnu.org > > With both emacs 26.3 and 27.1, iI do: > . emacs -Q > . C-x C-f lisp/simple.el > . C-u M-x cc-require > ==> message: No definitions found for cc-require > > At this point: > - the xref backend is the default for .el files; etags. > - xref-backend-functions is set to (elisp--xref-backend t), a local setting. > - the abbrev feature is loaded, as M-: (featurep 'abbrev) returns t. > - So looking for kill-all-abbrevs using the elisp--xref-backend works, my > understanding is that it works because the file that holds the definition > is loaded. How does this explain the fact that find-tag also worked for me? Does it work for you?
bug-gnu-emacs@HIDDEN:bug#44494; Package emacs.
Full text available.Received: (at 44494) by debbugs.gnu.org; 7 Nov 2020 14:15:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 07 09:15:32 2020 Received: from localhost ([127.0.0.1]:58150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1kbP07-0006uH-Ci for submit <at> debbugs.gnu.org; Sat, 07 Nov 2020 09:15:32 -0500 Received: from mail-lf1-f50.google.com ([209.85.167.50]:34644) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <prouleau001@HIDDEN>) id 1kbP05-0006u3-Ov for 44494 <at> debbugs.gnu.org; Sat, 07 Nov 2020 09:15:30 -0500 Received: by mail-lf1-f50.google.com with SMTP id i6so5956329lfd.1 for <44494 <at> debbugs.gnu.org>; Sat, 07 Nov 2020 06:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XdQIsFRgMrzns4OMFAPDlsjDevcTVSyLuvgNDJOY65k=; b=vHxzrVb0XWyOGp+X84w4wpB+UYqm4gomCgCYpH0OLhkb4Nk31Ad+tmdp2/tGum/HT7 U5mE5iNrx07JqairJQs9pnvfUNcAhlnUYrUy1EbCNNZWMenq1Vj4KyJvQ57lunq5GBJ/ C/B702R3bja2QtOS/L6vHIZOqPLTyRR3M84iET2TiAn5ngIJNGip/kkHJ+2sp88prEL5 3XkkdaLCXUN5aeNocA+HOSI4D4BZ0taD7NxIyz5xOqX/VlcfoJY8TMEX3EB/PGyGMMRn gg8gAbfyNEUwFA44m02COQo66CpZsiSQKpX1dqtrUGA2Roqsl8oc+8lDEqW/synp+XFx XURA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XdQIsFRgMrzns4OMFAPDlsjDevcTVSyLuvgNDJOY65k=; b=HraHW5LBBxxR0UycGsppZNBq5Dd/sf10xv7H3/fd3zFpG5/R1e+5gmuIwrZcjH5Fvj elC0AmCHV4E95z9dmvgUYqNVwLz8r5WMce42/VIFZ+wegUJNqu6kNvxN5sMh1yHnZ/8c HNnUD9iSzM0zHuaV04d9u5S22exmjRz2Ks+6MrwznlW2iXRwqdbP+oVxwWxNs8EtSKNM cJnV1HWopLRp40r+FvCR7kWGwh0CUxbgKdxhppb4HZ3s8w8cPcDNN0YHL0N7PWPzkV8D AZ46DdLFapBO0gGfDwjodeJeYzesCBiVJ6OYD4yUC+ZjxmYXJR3RfYZPwYDWyYOOzwO0 oCIg== X-Gm-Message-State: AOAM530CNjdnsnZ8IStDZH2YqH9K4O/HXXH5i0RGOUg1wcnY1RmCuekf DLX43LPmBAfpCMkF1X2ST5Pw4IezUfnYqZlsrtI= X-Google-Smtp-Source: ABdhPJx5iCx/jaW13Adv1N6jlskct0fWFYe0c+AExg6eXnmE3G33eiCX2B+Af0aW+oe1dVrmwSBxgJIDYOkWxhXjON0= X-Received: by 2002:a19:686:: with SMTP id 128mr1426096lfg.198.1604758523669; Sat, 07 Nov 2020 06:15:23 -0800 (PST) MIME-Version: 1.0 References: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN> <1cdac9f7-8340-83eb-f619-583e028e6e23@HIDDEN> <CALTqLiZtHEjtHB7BGKuFknKDLgNvpbjDkfNhoK9pLFi7k2LYxQ@HIDDEN> <83wnyx7g0u.fsf@HIDDEN> In-Reply-To: <83wnyx7g0u.fsf@HIDDEN> From: Pierre Rouleau <prouleau001@HIDDEN> Date: Sat, 7 Nov 2020 09:15:12 -0500 Message-ID: <CALTqLiZuDKW3QJhfqEaK=J4aqJ_qAh-TTpB19sf0jg=d+w=bwA@HIDDEN> Subject: Re: bug#44494: etags.el xref-location-marker does not handle TAGS references to .el.gz files To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000c0ef4705b384f582" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 44494 Cc: 44494 <at> debbugs.gnu.org, dgutov@HIDDEN 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: -0.7 (/) --000000000000c0ef4705b384f582 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 7, 2020 at 3:00 AM Eli Zaretskii <eliz@HIDDEN> wrote: > > From: Pierre Rouleau <prouleau001@HIDDEN> > > Date: Fri, 6 Nov 2020 22:31:02 -0500 > > Cc: 44494 <at> debbugs.gnu.org > > > > Do you see the same problem with 'M-x find-tag'? > > > > Short answer: yes > > > > Longer answer: you can try it on Emacs lib files. > > > > For example, I created a TAGS file that contains the following: > > > > define-globalized-minor-mode global-prettify-symbols-mode^?247,10355 > > (define-derived-mode prog-mode ^?251,10485 > > ^L > > > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-bytecomp.= el,1014 > > (defvar cc-bytecomp-unbound-variables ^?76,2968 > > (defvar cc-bytecomp-original-functions ^?77,3011 > > (defvar cc-bytecomp-original-properties ^?78,3055 > > (defvar cc-bytecomp-loaded-files ^?79,3100 > > (defvar cc-bytecomp-environment-set ^?86,3302 > > (defmacro cc-bytecomp-debug-msg ^?88,3344 > > (defun cc-bytecomp-compiling-or-loading ^?93,3432 > > (defsubst cc-bytecomp-is-compiling ^?134,4714 > > (defsubst cc-bytecomp-is-loading ^?138,4857 > > (defun cc-bytecomp-setup-environment ^?143,5065 > > (defun cc-bytecomp-restore-environment ^?191,6703 > > (defun cc-bytecomp-load ^?256,8749 > > (defmacro cc-require ^?293,10222 > > (defmacro cc-conditional-require ^?305,10617 > > (defmacro cc-conditional-require-after-load ^?318,11068 > > (defmacro cc-provide ^?333,11627 > > (defmacro cc-load ^?340,11887 > > (defmacro cc-require-when-compile ^?351,12266 > > (defmacro cc-external-require ^?362,12703 > > (defmacro cc-bytecomp-defvar ^?371,13055 > > (defmacro cc-bytecomp-defun ^?392,13857 > > (defmacro cc-bytecomp-put ^?419,14990 > > (defmacro cc-bytecomp-boundp ^?437,15739 > > (defmacro cc-bytecomp-fboundp ^?447,16140 > > ^L > > > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/make-mode.el= ,6494 > > (defgroup makefile ^?95,3661 > > (defface makefile-space^?101,3839 > > (defface makefile-targets^?107,4026 > > (defface makefile-shell^?114,4302 > > > > Then with the file > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-cmds.el.g= z > in a buffer > > and cc-bytecomp not loaded trying both > > > > M-x xref-find-definitions cc-require > > > > and > > > > M-x find-tag cc-require > > > > I get: > > > > Rerun etags: =E2=80=98^(defmacro cc-require =E2=80=99 not found in > > > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-bytecomp.= el > > I cannot reproduce this: find-tag works in this situation, at least in > the current emacs-27 branch and in stock Emacs 27.1. Which doesn't > surprise me, since etags.el already has code that handles compressed > files. > > Moreover, M-. (which uses xref) works as well. So I'm no longer sure > I understand what is the problem you are seeing. If you see this in > Emacs 26, please retry in Emacs 27, and let's take this from there. > > FTR, the steps I used for reproducing were slightly different: > > . "make TAGS" in the top-level directory of the Emacs source tree > . gzip lisp/abbrevs.el > . emacs -Q > . C-x C-f lisp/simple.el > . C-u M-. kill-all-abbrevs RET > > And for find-tag, replace the last 2 commands with > > . M-x visit-tags-table RET RET > . M-x find-tag RET kill-all-abbrevs RET > > Both of these work and show abbrevs.el.gz at the correct line. > Hi, I did try your test, both on emacs 26.3 and 27.1, and for the exact scenario you described, it works if you search for kill-all-abbrevs. I should have better describe the failure scenario. - Problem occurs in emacs 26.3 and 27.1. - I search for cc-require , a defmacro, not a defun, and not something that is already loaded. - on my system all files emacs/lisp directory are .el.gz file, however, I do not think that the fact they are all compressed is significant. With both emacs 26.3 and 27.1, iI do: . emacs -Q . C-x C-f lisp/simple.el . C-u M-x cc-require =3D=3D> message: No definitions found for cc-require At this point: - the xref backend is the default for .el files; etags. - xref-backend-functions is set to (elisp--xref-backend t), a local setting= . - the abbrev feature is loaded, as M-: (featurep 'abbrev) returns t. - So looking for kill-all-abbrevs using the elisp--xref-backend works, my understanding is that it works because the file that holds the definition is loaded. I wanted to be able to access definitions from code that might not have already been loaded so I thought I would use the etags--xref-backend instead. With emacs 26.3 and 27.1 with all lisp/simple files compressed, I do (and get approximately same results, shown below): . emacs -Q . C-x C-f lisp/simple.el.gz . M-x xref-etags-mode . C-u M-x cc-require emacs=3D=3D> prompts Visit tags table (default TAGS): .... me =3D=3D=3D=3D> I select the TAGS file where all definitions are stored an= d hit RET - emacs 26.3 =3D=3D> Rerun etags: =E2=80=98^(defmacro cc-require =E2=80=99 = not found in /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmod\ es/cc-bytecomp.el - emacs 27.1 =3D=3D> Rerun etags: =E2=80=98^(defmacro cc-require =E2=80=99 = not found in /usr/local/Cellar/emacs/27.1/share/emacs/27.1/lisp/progmodes/cc-bytecomp.el If I look inside the TAGS file and search for cc-require, I see it listed under the cc-bytecomp.el file. If at this point, I load the 2 functions I wrote and try again, it succeeds in finding cc-require. To recap you need to try searching for something that is not already loaded and use the etags xref backend with a file that contains the definition of what one is searching and that is located inside a compressed file. Let me know if you want me to try other scenarios. Thanks! /Pierre Rouleau --000000000000c0ef4705b384f582 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Sat, Nov 7, 2020 at 3:00 AM Eli Zaretskii <<a href=3D"mailto:e= liz@HIDDEN">eliz@HIDDEN</a>> wrote:<br></div><blockquote class=3D"gmai= l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20= 4,204);padding-left:1ex">> From: Pierre Rouleau <<a href=3D"mailto:pr= ouleau001@HIDDEN" target=3D"_blank">prouleau001@HIDDEN</a>><br> > Date: Fri, 6 Nov 2020 22:31:02 -0500<br> > Cc: <a href=3D"mailto:44494 <at> debbugs.gnu.org" target=3D"_blank">44494@d= ebbugs.gnu.org</a><br> > <br> >=C2=A0 Do you see the same problem with 'M-x find-tag'?<br> > <br> > Short answer:=C2=A0 yes<br> > <br> > Longer answer:=C2=A0 you can try it on Emacs lib files.=C2=A0 <br> > <br> > For example, I created a TAGS file that contains the following:<br> > <br> > define-globalized-minor-mode global-prettify-symbols-mode^?247,10355<b= r> > (define-derived-mode prog-mode ^?251,10485<br> > ^L<br> > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-byteco= mp.el,1014<br> > (defvar cc-bytecomp-unbound-variables ^?76,2968<br> > (defvar cc-bytecomp-original-functions ^?77,3011<br> > (defvar cc-bytecomp-original-properties ^?78,3055<br> > (defvar cc-bytecomp-loaded-files ^?79,3100<br> > (defvar cc-bytecomp-environment-set ^?86,3302<br> > (defmacro cc-bytecomp-debug-msg ^?88,3344<br> > (defun cc-bytecomp-compiling-or-loading ^?93,3432<br> > (defsubst cc-bytecomp-is-compiling ^?134,4714<br> > (defsubst cc-bytecomp-is-loading ^?138,4857<br> > (defun cc-bytecomp-setup-environment ^?143,5065<br> > (defun cc-bytecomp-restore-environment ^?191,6703<br> > (defun cc-bytecomp-load ^?256,8749<br> > (defmacro cc-require ^?293,10222<br> > (defmacro cc-conditional-require ^?305,10617<br> > (defmacro cc-conditional-require-after-load ^?318,11068<br> > (defmacro cc-provide ^?333,11627<br> > (defmacro cc-load ^?340,11887<br> > (defmacro cc-require-when-compile ^?351,12266<br> > (defmacro cc-external-require ^?362,12703<br> > (defmacro cc-bytecomp-defvar ^?371,13055<br> > (defmacro cc-bytecomp-defun ^?392,13857<br> > (defmacro cc-bytecomp-put ^?419,14990<br> > (defmacro cc-bytecomp-boundp ^?437,15739<br> > (defmacro cc-bytecomp-fboundp ^?447,16140<br> > ^L<br> > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/make-mode= .el,6494<br> > (defgroup makefile ^?95,3661<br> > (defface makefile-space^?101,3839<br> > (defface makefile-targets^?107,4026<br> > (defface makefile-shell^?114,4302<br> > <br> > Then with the file /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/= progmodes/cc-cmds.el.gz in a buffer<br> > and cc-bytecomp not loaded trying both<br> > <br> > M-x xref-find-definitions cc-require<br> > <br> > and<br> > <br> > M-x find-tag cc-require<br> > <br> > I get: <br> > <br> > Rerun etags: =E2=80=98^(defmacro cc-require =E2=80=99 not found in<br> > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-byteco= mp.el<br> <br> I cannot reproduce this: find-tag works in this situation, at least in<br> the current emacs-27 branch and in stock Emacs 27.1.=C2=A0 Which doesn'= t<br> surprise me, since etags.el already has code that handles compressed<br> files.<br> <br> Moreover, M-. (which uses xref) works as well.=C2=A0 So I'm no longer s= ure<br> I understand what is the problem you are seeing.=C2=A0 If you see this in<b= r> Emacs 26, please retry in Emacs 27, and let's take this from there.<br> <br> FTR, the steps I used for reproducing were slightly different:<br> <br> =C2=A0 . "make TAGS" in the top-level directory of the Emacs sour= ce tree<br> =C2=A0 . gzip lisp/abbrevs.el<br> =C2=A0 . emacs -Q<br> =C2=A0 . C-x C-f lisp/simple.el<br> =C2=A0 . C-u M-. kill-all-abbrevs RET<br> <br> And for find-tag, replace the last 2 commands with<br> <br> =C2=A0 . M-x visit-tags-table RET RET<br> =C2=A0 . M-x find-tag RET kill-all-abbrevs RET<br> <br> Both of these work and show abbrevs.el.gz at the correct line.<br></blockqu= ote><div>=C2=A0</div></div><div>Hi,=C2=A0 I did try your test, both on emac= s 26.3 and 27.1,</div><div> and for the exact scenario you described, it wo= rks if you search for kill-all-abbrevs.<br></div><div><br></div><div>I shou= ld have better describe the failure scenario.=C2=A0 <br></div><div>- Proble= m=C2=A0 occurs in emacs 26.3 and 27.1.</div><div>- I search for cc-require = ,=C2=A0 a defmacro, not a defun, and not something</div><div>=C2=A0 that is= already loaded.<br></div><div>- on my system all files emacs/lisp director= y are .el.gz file, however, <br></div><div>=C2=A0 I do not think that the f= act they are all compressed is significant.</div><div><br></div><div>With b= oth emacs 26.3 and 27.1, iI do:<br></div><div>. emacs -Q</div><div>. C-x C-= f lisp/simple.el</div><div>. C-u M-x cc-require</div><div>=3D=3D> messag= e: No definitions found for cc-require</div><div><br></div><div>At this poi= nt:</div><div>- the xref backend is the default for .el files; etags.</div>= <div>- xref-backend-functions is set to (elisp--xref-backend t), a local se= tting.</div><div>- the abbrev feature is loaded, as M-: (featurep 'abbr= ev) returns t.</div><div>- So looking for kill-all-abbrevs using the elisp-= -xref-backend works, my <br></div><div>=C2=A0 understanding is that it work= s because the file that holds the definition <br></div><div>=C2=A0 is loade= d.<br></div><div><br></div><div>I wanted to be able to access definitions f= rom code that might not have</div><div> already been loaded so I thought I = would use the etags--xref-backend instead.</div><div><br></div><div>With em= acs 26.3 and 27.1 with all lisp/simple files compressed,</div><div>=C2=A0I = do (and get approximately same results, shown below):</div><div>. emacs -Q<= /div><div>. C-x C-f lisp/simple.el.gz</div><div>. M-x xref-etags-mode<br></= div><div>. C-u M-x cc-require</div><div>emacs=3D=3D> prompts Visit tags = table (default TAGS): ....</div><div>me =3D=3D=3D=3D> I select the TAGS = file where all definitions are stored and hit RET<br></div><div>- emacs 26.= 3 =3D=3D> Rerun etags: =E2=80=98^(defmacro cc-require =E2=80=99 not foun= d in /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmod\<br>es/cc-b= ytecomp.el</div><div>- emacs 27.1 =3D=3D> Rerun etags: =E2=80=98^(defmac= ro cc-require =E2=80=99 not found in /usr/local/Cellar/emacs/27.1/share/ema= cs/27.1/lisp/progmodes/cc-bytecomp.el</div><div><br></div><div>If I look in= side the TAGS file and search for cc-require,</div><div> I see it listed un= der the cc-bytecomp.el file.=C2=A0 <br></div><div><br></div><div>If at this= point, I load the 2 functions I wrote and try again, <br></div><div>it suc= ceeds in finding cc-require.</div><div><br></div><div>To recap you need to = try searching for something that is not already <br></div><div>loaded and u= se the etags xref backend with a file that contains the definition</div><di= v>of what one is searching and that is located inside a compressed file.</d= iv><div><br></div><div>Let me know if you want me to try other scenarios.</= div><div><br></div><div>Thanks!</div><div><br></div><div>/Pierre Rouleau<br= ></div><div><br></div><br></div> --000000000000c0ef4705b384f582--
bug-gnu-emacs@HIDDEN:bug#44494; Package emacs.
Full text available.Received: (at 44494) by debbugs.gnu.org; 7 Nov 2020 08:00:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 07 03:00:42 2020 Received: from localhost ([127.0.0.1]:57878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1kbJ9O-000454-5l for submit <at> debbugs.gnu.org; Sat, 07 Nov 2020 03:00:42 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1kbJ9M-00044s-JI for 44494 <at> debbugs.gnu.org; Sat, 07 Nov 2020 03:00:40 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55034) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1kbJ9G-0002FF-Rd; Sat, 07 Nov 2020 03:00:34 -0500 Received: from [176.228.60.248] (port=4059 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1kbJ9E-0006MC-Rl; Sat, 07 Nov 2020 03:00:33 -0500 Date: Sat, 07 Nov 2020 10:00:33 +0200 Message-Id: <83wnyx7g0u.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pierre Rouleau <prouleau001@HIDDEN> In-Reply-To: <CALTqLiZtHEjtHB7BGKuFknKDLgNvpbjDkfNhoK9pLFi7k2LYxQ@HIDDEN> (message from Pierre Rouleau on Fri, 6 Nov 2020 22:31:02 -0500) Subject: Re: bug#44494: etags.el xref-location-marker does not handle TAGS references to .el.gz files References: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN> <1cdac9f7-8340-83eb-f619-583e028e6e23@HIDDEN> <CALTqLiZtHEjtHB7BGKuFknKDLgNvpbjDkfNhoK9pLFi7k2LYxQ@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44494 Cc: 44494 <at> debbugs.gnu.org, dgutov@HIDDEN 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: Pierre Rouleau <prouleau001@HIDDEN> > Date: Fri, 6 Nov 2020 22:31:02 -0500 > Cc: 44494 <at> debbugs.gnu.org > > Do you see the same problem with 'M-x find-tag'? > > Short answer: yes > > Longer answer: you can try it on Emacs lib files. > > For example, I created a TAGS file that contains the following: > > define-globalized-minor-mode global-prettify-symbols-mode^?247,10355 > (define-derived-mode prog-mode ^?251,10485 > ^L > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-bytecomp.el,1014 > (defvar cc-bytecomp-unbound-variables ^?76,2968 > (defvar cc-bytecomp-original-functions ^?77,3011 > (defvar cc-bytecomp-original-properties ^?78,3055 > (defvar cc-bytecomp-loaded-files ^?79,3100 > (defvar cc-bytecomp-environment-set ^?86,3302 > (defmacro cc-bytecomp-debug-msg ^?88,3344 > (defun cc-bytecomp-compiling-or-loading ^?93,3432 > (defsubst cc-bytecomp-is-compiling ^?134,4714 > (defsubst cc-bytecomp-is-loading ^?138,4857 > (defun cc-bytecomp-setup-environment ^?143,5065 > (defun cc-bytecomp-restore-environment ^?191,6703 > (defun cc-bytecomp-load ^?256,8749 > (defmacro cc-require ^?293,10222 > (defmacro cc-conditional-require ^?305,10617 > (defmacro cc-conditional-require-after-load ^?318,11068 > (defmacro cc-provide ^?333,11627 > (defmacro cc-load ^?340,11887 > (defmacro cc-require-when-compile ^?351,12266 > (defmacro cc-external-require ^?362,12703 > (defmacro cc-bytecomp-defvar ^?371,13055 > (defmacro cc-bytecomp-defun ^?392,13857 > (defmacro cc-bytecomp-put ^?419,14990 > (defmacro cc-bytecomp-boundp ^?437,15739 > (defmacro cc-bytecomp-fboundp ^?447,16140 > ^L > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/make-mode.el,6494 > (defgroup makefile ^?95,3661 > (defface makefile-space^?101,3839 > (defface makefile-targets^?107,4026 > (defface makefile-shell^?114,4302 > > Then with the file /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-cmds.el.gz in a buffer > and cc-bytecomp not loaded trying both > > M-x xref-find-definitions cc-require > > and > > M-x find-tag cc-require > > I get: > > Rerun etags: ‘^(defmacro cc-require ’ not found in > /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-bytecomp.el I cannot reproduce this: find-tag works in this situation, at least in the current emacs-27 branch and in stock Emacs 27.1. Which doesn't surprise me, since etags.el already has code that handles compressed files. Moreover, M-. (which uses xref) works as well. So I'm no longer sure I understand what is the problem you are seeing. If you see this in Emacs 26, please retry in Emacs 27, and let's take this from there. FTR, the steps I used for reproducing were slightly different: . "make TAGS" in the top-level directory of the Emacs source tree . gzip lisp/abbrevs.el . emacs -Q . C-x C-f lisp/simple.el . C-u M-. kill-all-abbrevs RET And for find-tag, replace the last 2 commands with . M-x visit-tags-table RET RET . M-x find-tag RET kill-all-abbrevs RET Both of these work and show abbrevs.el.gz at the correct line.
bug-gnu-emacs@HIDDEN:bug#44494; Package emacs.
Full text available.
Received: (at 44494) by debbugs.gnu.org; 7 Nov 2020 07:19:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 07 02:19:01 2020
Received: from localhost ([127.0.0.1]:57863 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1kbIV3-00037F-D0
for submit <at> debbugs.gnu.org; Sat, 07 Nov 2020 02:19:01 -0500
Received: from eggs.gnu.org ([209.51.188.92]:33990)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1kbIV1-000370-Sx
for 44494 <at> debbugs.gnu.org; Sat, 07 Nov 2020 02:19:00 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e]:54840)
by eggs.gnu.org with esmtp (Exim 4.90_1)
(envelope-from <eliz@HIDDEN>)
id 1kbIUw-0004rt-LB; Sat, 07 Nov 2020 02:18:54 -0500
Received: from [176.228.60.248] (port=1499 helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
(Exim 4.82) (envelope-from <eliz@HIDDEN>)
id 1kbIUw-000737-1m; Sat, 07 Nov 2020 02:18:54 -0500
Date: Sat, 07 Nov 2020 09:18:55 +0200
Message-Id: <83zh3t7hy8.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pierre Rouleau <prouleau001@HIDDEN>
In-Reply-To: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN>
(message from Pierre Rouleau on Fri, 6 Nov 2020 18:22:46 -0500)
Subject: Re: bug#44494: etags.el xref-location-marker does not handle TAGS
references to .el.gz files
References: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 44494
Cc: 44494 <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: Pierre Rouleau <prouleau001@HIDDEN>
> Date: Fri, 6 Nov 2020 18:22:46 -0500
>
> One could consider that the issue is inside the etags utility.
I don't think this is the best alternative. TAGS tables are supposed
to provide information in a way that doesn't require re-running etags
each time some change in the sources is made. The way things are now,
compressing or decompressing a file doesn't require re-running etags,
which is a Good Thing.
Handling this in the code which accesses and interprets TAGS sounds
like a better alternative.
> Here's a proposal for a solution:
>
> (defun etags-file-or-compressed-file-for (fname)
> "Return the valid file name for FNAME.
> Check if FNAME is an existing file name, if not
> try FNAME appended with the following compression extensions:
> - \".gz\", the extension of compressed files created by gzip
> - \".bz2\", the extension for compressed files created by bzip2
> - \".xz\", the extension for compressed files created by xz
> - \".lzma\", the extension for compressed files created by xz.
>
> Return the file that exists or nil if nothing found."
> (let ((fpath nil))
> (cl-dolist (ext '(""
> ".gz"
> ".bz2"
> ".xz"
> ".lzma"))
> (setq fpath (concat fname ext))
> (when (file-exists-p fpath)
> (cl-return fpath)))))
We already have in etags.el support for finding compressed files, see
tag-find-file-of-tag-noselect. Can't that be reused? If not, let's
at least reuse tags-compression-info-list, okay?
bug-gnu-emacs@HIDDEN:bug#44494; Package emacs.
Full text available.Received: (at 44494) by debbugs.gnu.org; 7 Nov 2020 03:31:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 06 22:31:21 2020 Received: from localhost ([127.0.0.1]:57764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1kbEwj-0003zj-FU for submit <at> debbugs.gnu.org; Fri, 06 Nov 2020 22:31:21 -0500 Received: from mail-wr1-f49.google.com ([209.85.221.49]:39856) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <prouleau001@HIDDEN>) id 1kbEwh-0003zV-KW for 44494 <at> debbugs.gnu.org; Fri, 06 Nov 2020 22:31:20 -0500 Received: by mail-wr1-f49.google.com with SMTP id y12so3246785wrp.6 for <44494 <at> debbugs.gnu.org>; Fri, 06 Nov 2020 19:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NbKSjzAKj1rbqtZiHNh2Kh5yTNBy0shbI6akm3KwIRc=; b=a77FkbiKOZdOjCw/tg5AKb/CaKJhMCglbw7Gz/GcPp8ACCCs7PVwvF726IzjmeMKvI jgW9W+gt863k6SpdosTCMAM8ssMI0c4VOsOFJpqsO6R6TywdxkgyVXtJDyWzX3lpYVWx VQklPU8RONYO1x/YPlup2GIR5D2pCMzQMwRSndXyDtrbzjju9serY3zwlGJEj5cRtoiD bkyNIyNeWb5RLlWTG2/Y2083e9Araqq3mcK2nF8VDGX/L8besAK5Ypwc+uDh+f0Zrwj/ CZ7KeaZez0ts7wR8kthbvuuchSH+LDhaWUSYxg5csYcmoS+FWH/rFeVIBg+xTv61Wgvv mLQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NbKSjzAKj1rbqtZiHNh2Kh5yTNBy0shbI6akm3KwIRc=; b=CSjh5anmDaouGy5jMGYBUewBc/YWB2xpnPooc1Q6Rbri/3NhiO3r1R5LBpTBAYpRDB 0FZFhgJW+Pm3/Gtd0oRK2Wac4CJ0c2Q/eM53TXo3uwcjS2CvIK1JVZrtooQI8Xt5zUf/ S4EwJjEl/E7dxuq5JDvbaow/5fGvylx382XFXWXlqE3yrjtUVG/pZIadNieNb9hmPiS5 ILLmDYUaS7HXxhzRej9r9S7IiQD8tRpY001AXYrZpKyNJUZ6TFBca7VB1bX90hKRGvYk Y6fUga7zHOonJYOzE1NIEZqcFat9V8DgA1VZF0VmTMuT/uV39q8rUvcBlZ9GWMsR2Qb+ XwBA== X-Gm-Message-State: AOAM533skdQeJwQBFYuIbFzz45gLaqOc9zV2lUNGEQh7pybWrpQmgatp w5u46oASICROVWRYksHMhrqPUDT84QjzVdA4ESc= X-Google-Smtp-Source: ABdhPJxTLl1WCoOGRqiwXYsGS0mDGrY5QiMc0PZCH2B6SMVz6vKwpMN0bvWlE07FofOKAAcSfVNwC9PWqy67Bg7fTtU= X-Received: by 2002:a5d:4104:: with SMTP id l4mr4400701wrp.276.1604719873710; Fri, 06 Nov 2020 19:31:13 -0800 (PST) MIME-Version: 1.0 References: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN> <1cdac9f7-8340-83eb-f619-583e028e6e23@HIDDEN> In-Reply-To: <1cdac9f7-8340-83eb-f619-583e028e6e23@HIDDEN> From: Pierre Rouleau <prouleau001@HIDDEN> Date: Fri, 6 Nov 2020 22:31:02 -0500 Message-ID: <CALTqLiZtHEjtHB7BGKuFknKDLgNvpbjDkfNhoK9pLFi7k2LYxQ@HIDDEN> Subject: Re: bug#44494: etags.el xref-location-marker does not handle TAGS references to .el.gz files To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000095f0c05b37bf6c2" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 44494 Cc: 44494 <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: -0.7 (/) --000000000000095f0c05b37bf6c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 6, 2020 at 9:22 PM Dmitry Gutov <dgutov@HIDDEN> wrote: > On 07.11.2020 01:22, Pierre Rouleau wrote: > > This problem was detected in emacs 26.3, but is also present in emacs > > 27.1, according to the code posted inside > > > https://github.com/emacs-mirror/emacs/blob/master/test/manual/etags/el-sr= c/emacs/lisp/progmodes/etags.el#L2139 > > Hi! > > Do you see the same problem with 'M-x find-tag'? > Short answer: yes Longer answer: you can try it on Emacs lib files. For example, I created a TAGS file that contains the following: define-globalized-minor-mode global-prettify-symbols-mode^?247,10355 (define-derived-mode prog-mode ^?251,10485 ^L /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-bytecomp.el= ,1014 (defvar cc-bytecomp-unbound-variables ^?76,2968 (defvar cc-bytecomp-original-functions ^?77,3011 (defvar cc-bytecomp-original-properties ^?78,3055 (defvar cc-bytecomp-loaded-files ^?79,3100 (defvar cc-bytecomp-environment-set ^?86,3302 (defmacro cc-bytecomp-debug-msg ^?88,3344 (defun cc-bytecomp-compiling-or-loading ^?93,3432 (defsubst cc-bytecomp-is-compiling ^?134,4714 (defsubst cc-bytecomp-is-loading ^?138,4857 (defun cc-bytecomp-setup-environment ^?143,5065 (defun cc-bytecomp-restore-environment ^?191,6703 (defun cc-bytecomp-load ^?256,8749 (defmacro cc-require ^?293,10222 (defmacro cc-conditional-require ^?305,10617 (defmacro cc-conditional-require-after-load ^?318,11068 (defmacro cc-provide ^?333,11627 (defmacro cc-load ^?340,11887 (defmacro cc-require-when-compile ^?351,12266 (defmacro cc-external-require ^?362,12703 (defmacro cc-bytecomp-defvar ^?371,13055 (defmacro cc-bytecomp-defun ^?392,13857 (defmacro cc-bytecomp-put ^?419,14990 (defmacro cc-bytecomp-boundp ^?437,15739 (defmacro cc-bytecomp-fboundp ^?447,16140 ^L /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/make-mode.el,6= 494 (defgroup makefile ^?95,3661 (defface makefile-space^?101,3839 (defface makefile-targets^?107,4026 (defface makefile-shell^?114,4302 Then with the file /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-cmds.el.gz in a buffer and cc-bytecomp not loaded trying both M-x xref-find-definitions cc-require and M-x find-tag cc-require I get: Rerun etags: =E2=80=98^(defmacro cc-require =E2=80=99 not found in /usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-bytecomp.el If I update the etags.el with my suggested code, M-x xref-find-definition works but find-tag still does not. Since find-tag is obsolete since emacs 25.1 I did not look into it. I did not look into the etags utility itself yet. This looks like a consistency problem. I would think that the etags utility should generate a reference for el.gz files listing the real file name. On the other hand having the fix in both places both in etags utility and in emacs etags.el would reduce probability of errors. --=20 /Pierre --000000000000095f0c05b37bf6c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g= mail_attr">On Fri, Nov 6, 2020 at 9:22 PM Dmitry Gutov <<a href=3D"mailt= o:dgutov@HIDDEN">dgutov@HIDDEN</a>> wrote:<br></div><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid= rgb(204,204,204);padding-left:1ex">On 07.11.2020 01:22, Pierre Rouleau wro= te:<br> > This problem was detected in emacs 26.3, but is also present in emacs = <br> > 27.1, according to the code posted inside <br> > <a href=3D"https://github.com/emacs-mirror/emacs/blob/master/test/manu= al/etags/el-src/emacs/lisp/progmodes/etags.el#L2139" rel=3D"noreferrer" tar= get=3D"_blank">https://github.com/emacs-mirror/emacs/blob/master/test/manua= l/etags/el-src/emacs/lisp/progmodes/etags.el#L2139</a><br> <br> Hi!<br> <br> Do you see the same problem with 'M-x find-tag'?<br></blockquote><d= iv><br></div><div>Short answer:=C2=A0 yes</div><div><br></div><div>Longer a= nswer:=C2=A0 you can try it on Emacs lib files.=C2=A0 <br></div><div><br></= div><div>For example, I created a TAGS file that contains the following:</d= iv><div><br></div><div style=3D"margin-left:40px">define-globalized-minor-m= ode global-prettify-symbols-mode^?247,10355<br>(define-derived-mode prog-mo= de ^?251,10485<br>^L<br>/usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/= progmodes/cc-bytecomp.el,1014<br>(defvar cc-bytecomp-unbound-variables ^?76= ,2968<br>(defvar cc-bytecomp-original-functions ^?77,3011<br>(defvar cc-byt= ecomp-original-properties ^?78,3055<br>(defvar cc-bytecomp-loaded-files ^?7= 9,3100<br>(defvar cc-bytecomp-environment-set ^?86,3302<br>(defmacro cc-byt= ecomp-debug-msg ^?88,3344<br>(defun cc-bytecomp-compiling-or-loading ^?93,3= 432<br>(defsubst cc-bytecomp-is-compiling ^?134,4714<br>(defsubst cc-byteco= mp-is-loading ^?138,4857<br>(defun cc-bytecomp-setup-environment ^?143,5065= <br>(defun cc-bytecomp-restore-environment ^?191,6703<br>(defun cc-bytecomp= -load ^?256,8749<br>(defmacro cc-require ^?293,10222<br>(defmacro cc-condit= ional-require ^?305,10617<br>(defmacro cc-conditional-require-after-load ^?= 318,11068<br>(defmacro cc-provide ^?333,11627<br>(defmacro cc-load ^?340,11= 887<br>(defmacro cc-require-when-compile ^?351,12266<br>(defmacro cc-extern= al-require ^?362,12703<br>(defmacro cc-bytecomp-defvar ^?371,13055<br>(defm= acro cc-bytecomp-defun ^?392,13857<br>(defmacro cc-bytecomp-put ^?419,14990= <br>(defmacro cc-bytecomp-boundp ^?437,15739<br>(defmacro cc-bytecomp-fboun= dp ^?447,16140<br>^L<br>/usr/local/Cellar/emacs/26.3/share/emacs/26.3/lisp/= progmodes/make-mode.el,6494<br>(defgroup makefile ^?95,3661<br>(defface mak= efile-space^?101,3839<br>(defface makefile-targets^?107,4026<br>(defface ma= kefile-shell^?114,4302</div><div style=3D"margin-left:40px"><br></div><div>= <br></div><div>Then with the file /usr/local/Cellar/emacs/26.3/share/emacs/= 26.3/lisp/progmodes/cc-cmds.el.gz in a buffer and cc-bytecomp not loaded tr= ying both</div><div><br></div><div>M-x xref-find-definitions cc-require<br>= </div><div><br></div><div>and</div><div><br></div><div>M-x find-tag cc-requ= ire<br></div><div><br></div><div>I get: <br></div><div><br></div><div>Rerun= etags: =E2=80=98^(defmacro cc-require =E2=80=99 not found in /usr/local/Ce= llar/emacs/26.3/share/emacs/26.3/lisp/progmodes/cc-bytecomp.el</div></div><= br clear=3D"all"><div>If I update the etags.el with my suggested code, M-x = xref-find-definition works but find-tag still does not.=C2=A0=C2=A0=C2=A0 <= br></div><div>Since find-tag is obsolete since emacs 25.1 I did not look in= to it.</div><div><br></div><div><br></div><div>I did not look into the etag= s utility itself yet.=C2=A0 This looks like a consistency problem.=C2=A0 <b= r></div><div>I would think that the etags utility should generate a referen= ce for el.gz files listing <br></div><div>the real file name.=C2=A0 On the = other hand having the fix in both places both in etags utility</div><div> a= nd in emacs etags.el would reduce probability of errors. <br></div><div><br= ></div><div><br></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature">/Pi= erre</div></div> --000000000000095f0c05b37bf6c2--
bug-gnu-emacs@HIDDEN:bug#44494; Package emacs.
Full text available.Received: (at 44494) by debbugs.gnu.org; 7 Nov 2020 02:22:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 06 21:22:10 2020 Received: from localhost ([127.0.0.1]:57729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1kbDrm-0002NY-L1 for submit <at> debbugs.gnu.org; Fri, 06 Nov 2020 21:22:10 -0500 Received: from mail-ej1-f52.google.com ([209.85.218.52]:42279) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1kbDrk-0002NL-So for 44494 <at> debbugs.gnu.org; Fri, 06 Nov 2020 21:22:09 -0500 Received: by mail-ej1-f52.google.com with SMTP id i19so4516658ejx.9 for <44494 <at> debbugs.gnu.org>; Fri, 06 Nov 2020 18:22:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=DsXazmIlnbxezrqEY0DIaWbw2+ZkCQKXDphQ2QrFrus=; b=CcgrHvGLJMYoK3G2VpcUM/Io5jdLDnVFkWs/fHsUr5WgcMo90kO8MvdDCFRqJyfXha zCmn168QaoEf9kfrNuhw0QQoecdrH+jy7P/h1QaP3ONDEqmkUobwOjgXtzIDAYJw85Lo TFhko3IrvZoLjNtMoFUnSi79KnPjKoPzMqGpM1RS3INyQ8Tb5Dul4GjLmueCqI/9MKm+ eDzEry7/onRT8bUuu3h3MHtdSPSX9SzgLIUvNMsynYIhGwaxBtbQV2FNY8bI3lc/PLCR FiEb92pNM5K7HgyrywMJMbhTykD/fFLi4lbv3F/Gb0SaY1EzObJObU77s/bIOsjMSN7d m4TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DsXazmIlnbxezrqEY0DIaWbw2+ZkCQKXDphQ2QrFrus=; b=VebomeKsXaoNop0s6vDJN5OEKnUQsd2bwu51Jz/aYOV4njDq0Qt4sbHEqZlcX5oGsw K/ugmo1Nhx74dAVsFL58RiJOS5LACbWZls1h4RrzCwFgfLRc0p9/xAGhZcjD+VUPqV5C 6M+zm1wbmAMrQX1f26u32M6G8N3BK7Eyt9PmDbIHqaTCLq6dLmgKrTRZgVSqg9pgP0Z0 2M5asmlqFXa41ay34sGCjAPJlzDDkY+C3rGk3Im9r/xhna5bTNc4uW+T/BbEOONjIcX5 XYetmo7lKTUOFQk5WC7BfGpIfMq3h3nucIhh7CORxckOFhCjENswxQ0H2/TDBNOF4PPU ttcA== X-Gm-Message-State: AOAM533a6aJc/qnWQTLk6Ad6lThuHseKvRZtOAvPYNsq69L0oEA+B9ae WEyX8MOuRr9XefoQFoAfyApKwWWrf0q0jg== X-Google-Smtp-Source: ABdhPJzWuhatMx9BloUn2xlIjQ5OIRf64SvLtGl6qfZlbXsUQeV/T0x30p7VG4TW9r8ygykfZg8i0Q== X-Received: by 2002:a17:906:3089:: with SMTP id 9mr5077952ejv.535.1604715722784; Fri, 06 Nov 2020 18:22:02 -0800 (PST) Received: from [192.168.0.4] ([66.205.71.3]) by smtp.googlemail.com with ESMTPSA id o20sm2181957eja.34.2020.11.06.18.22.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Nov 2020 18:22:01 -0800 (PST) Subject: Re: bug#44494: etags.el xref-location-marker does not handle TAGS references to .el.gz files To: Pierre Rouleau <prouleau001@HIDDEN>, 44494 <at> debbugs.gnu.org References: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <1cdac9f7-8340-83eb-f619-583e028e6e23@HIDDEN> Date: Sat, 7 Nov 2020 04:22:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 44494 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: -0.5 (/) On 07.11.2020 01:22, Pierre Rouleau wrote: > This problem was detected in emacs 26.3, but is also present in emacs > 27.1, according to the code posted inside > https://github.com/emacs-mirror/emacs/blob/master/test/manual/etags/el-src/emacs/lisp/progmodes/etags.el#L2139 Hi! Do you see the same problem with 'M-x find-tag'?
bug-gnu-emacs@HIDDEN:bug#44494; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 6 Nov 2020 23:23:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 06 18:23:06 2020
Received: from localhost ([127.0.0.1]:57588 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1kbB4U-0004V4-3R
for submit <at> debbugs.gnu.org; Fri, 06 Nov 2020 18:23:06 -0500
Received: from lists.gnu.org ([209.51.188.17]:37918)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <prouleau001@HIDDEN>) id 1kbB4T-0004Ux-5n
for submit <at> debbugs.gnu.org; Fri, 06 Nov 2020 18:23:05 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:57874)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <prouleau001@HIDDEN>)
id 1kbB4S-00016P-W3
for bug-gnu-emacs@HIDDEN; Fri, 06 Nov 2020 18:23:05 -0500
Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:37887)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <prouleau001@HIDDEN>)
id 1kbB4P-00016V-AM
for bug-gnu-emacs@HIDDEN; Fri, 06 Nov 2020 18:23:04 -0500
Received: by mail-wr1-x429.google.com with SMTP id w1so2947306wrm.4
for <bug-gnu-emacs@HIDDEN>; Fri, 06 Nov 2020 15:22:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=eVqDBdfsSRl1uB9eBrmghhoiN0DWZyzgA2lBOrA/5+A=;
b=R79MybzYoGlX8J4eEs9lYDWRBxUw1DzaoQXVBsC63qSNf0d3XyXApUWMsGxHxrVHZk
WET8pvzb9CcAofmd3QzFcYvOqD215iBdW55HE7sJIcRrbSewsgsHSfaylENR8xuJ9Pg/
b+w5zHBm3xauiOPpKLEB1dURR6fDavCfFF+Wu+AQ64gAG54CIOTdGOqbJ33qDacZz1sO
myOBFkOujSUgBATOyezx9ONYj+upsV/Pog6id4QrLunvuftyoFZ98kc0/9Zv7z8WtuTJ
22llo2h5QuhRxcqPx4r36R2x6R4H1Ins3FM4QQTFRROf0es44XPw2lrYsExqj97Qwje6
1wGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=eVqDBdfsSRl1uB9eBrmghhoiN0DWZyzgA2lBOrA/5+A=;
b=rWpYbmhdK0I85O1q5xM7jskauTxVDUexOhvhltk7XXkrK6Kugk5N8y/6XRV6xHzGGo
206Nnzh8AVW/R1Ta0FNRl0XVCJOCEjjini/smjT2GhViKzZCtaonyCgnocBtfXr5+8qC
VnhG/Dashj+vfYIXi6EefszJZpyIFqSkBLsTfV0VJmO47hufLWx/I1/cpAuFxHII04m3
xKSQDszOqSHOFPSlQwCX2HKjOIhhxjnQrVv4yQiu57oeAAlVYixuevzD3c03KptD1Dan
RXDTSFXJA5Y5PBL8PkXx6T9iX9d1kC2MQKjSW6uyQxxstSacZKIwn/JdOAPO8enng/BL
+/MQ==
X-Gm-Message-State: AOAM531reZ6CVVdTDVysCRXin3I86WALrURpkPKohaqhCzdI5jslQTY2
2IhFynSShnHYZh2EGf5JILvT0i+saStJnKZ/TwTBNJqDHQw=
X-Google-Smtp-Source: ABdhPJwkLYTrIXaM4n9xgaPzUoPIxKVX9nEgtv75zz9BzhwbPnAxVC4TVQAZ29OUuoqVKuml/WZ+Kx21TlWgbA4BVxw=
X-Received: by 2002:a5d:4104:: with SMTP id l4mr3619002wrp.276.1604704977770;
Fri, 06 Nov 2020 15:22:57 -0800 (PST)
MIME-Version: 1.0
From: Pierre Rouleau <prouleau001@HIDDEN>
Date: Fri, 6 Nov 2020 18:22:46 -0500
Message-ID: <CALTqLiZ4ELYsP=Sabau7eoUu3LGvg0HiNxtH9FQfnq+ZFi-VWQ@HIDDEN>
Subject: etags.el xref-location-marker does not handle TAGS references to
.el.gz files
To: bug-gnu-emacs@HIDDEN
Content-Type: multipart/alternative; boundary="0000000000002b5d5505b3787e54"
Received-SPF: pass client-ip=2a00:1450:4864:20::429;
envelope-from=prouleau001@HIDDEN; helo=mail-wr1-x429.google.com
X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache.
That's all we know.
X-Spam_score_int: -17
X-Spam_score: -1.8
X-Spam_bar: -
X-Spam_report: (-1.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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
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.1 (--)
--0000000000002b5d5505b3787e54
Content-Type: text/plain; charset="UTF-8"
This problem was detected in emacs 26.3, but is also present in emacs 27.1,
according to the code posted inside
https://github.com/emacs-mirror/emacs/blob/master/test/manual/etags/el-src/emacs/lisp/progmodes/etags.el#L2139
Problem description follows:
----------------------------BUG DESCRIPTION [ ------------------------------
The current version of etags distributed with emacs 27.0 is capable of
parsing compressed files like something.el.gz but unfortunately the
reference inside the generated TAGS file uses the name "something.el"
instead of the complete file name "something.el.gz". The same is true
for the other compressed files (.bz2, .xz and .lzma).
When trying to use the etags xref back-end to move point to a definition
inside such a file, the xref-find-definitions command will fail because the
TAGS file identifies the .el file instead of the .el.gz file.
xref-find-definitions fails because it only checks if the uncompressed
file exists, it does not try to see if the compressed file exists.
The issue is inside etags.el xref-location-marker method.
The current code is:
(cl-defmethod xref-location-marker ((l xref-etags-location))
(with-slots (tag-info file) l
(let ((buffer (find-file-noselect file)))
(with-current-buffer buffer
(save-excursion
(etags-goto-tag-location tag-info)
(point-marker))))))
One could consider that the issue is inside the etags utility.
An alternative would be to provide Emacs with the ability to check
for the presence of the .el file and if it is not present look for the
equivalent compressed files.
Here's a proposal for a solution:
(defun etags-file-or-compressed-file-for (fname)
"Return the valid file name for FNAME.
Check if FNAME is an existing file name, if not
try FNAME appended with the following compression extensions:
- \".gz\", the extension of compressed files created by gzip
- \".bz2\", the extension for compressed files created by bzip2
- \".xz\", the extension for compressed files created by xz
- \".lzma\", the extension for compressed files created by xz.
Return the file that exists or nil if nothing found."
(let ((fpath nil))
(cl-dolist (ext '(""
".gz"
".bz2"
".xz"
".lzma"))
(setq fpath (concat fname ext))
(when (file-exists-p fpath)
(cl-return fpath)))))
(cl-defmethod xref-location-marker ((l xref-etags-location))
(with-slots (tag-info file) l
(let (buffer
(fname (pel-file-or-compressed-file-for file)))
(if fname
(setq buffer (find-file-noselect fname))
(user-error "file %s (or .gz, .bz2, .xz, .lzma) does not exist"
file))
(with-current-buffer buffer
(save-excursion
(etags-goto-tag-location tag-info)
(point-marker))))))
------------------------------ END OF DESCRIPTION ]
--------------------------------
In GNU Emacs 26.3 (build 1, x86_64-apple-darwin18.6.0)
of 2019-08-30 built on Mojave.local
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured using:
'configure --disable-dependency-tracking --disable-silent-rules
--enable-locallisppath=/usr/local/share/emacs/site-lisp
--infodir=/usr/local/Cellar/emacs/26.3/share/info/emacs
--prefix=/usr/local/Cellar/emacs/26.3 --with-gnutls --without-x
--with-xml2 --without-dbus --with-modules --without-ns
--without-imagemagick'
Configured features:
NOTIFY ACL GNUTLS LIBXML2 ZLIB MODULES THREADS
Important settings:
value of $LANG: en_CA.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail tool-bar rmail-loaddefs mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
regexp-opt rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
term/xterm xterm time-date elec-pair mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads kqueue
multi-tty make-network-process emacs)
Memory information:
((conses 16 96177 5831)
(symbols 48 19813 1)
(miscs 40 33 96)
(strings 32 28253 1011)
(string-bytes 1 748198)
(vectors 16 11977)
(vector-slots 8 455846 6474)
(floats 8 48 566)
(intervals 56 197 0)
(buffers 992 11))
;; ---------------------------
Thank you,
/Pierre Rouleau
--0000000000002b5d5505b3787e54
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>This problem was detected in emacs 26.3, but is also =
present in emacs 27.1, according to the code posted inside <a href=3D"https=
://github.com/emacs-mirror/emacs/blob/master/test/manual/etags/el-src/emacs=
/lisp/progmodes/etags.el#L2139">https://github.com/emacs-mirror/emacs/blob/=
master/test/manual/etags/el-src/emacs/lisp/progmodes/etags.el#L2139</a></di=
v><div><br></div><div>Problem description follows:<br></div><div><br></div>=
<div><br></div><div><br></div><div>----------------------------BUG DESCRIPT=
ION [ ------------------------------<br></div><div><br></div><div>The curre=
nt version of etags distributed with emacs 27.0 is capable of</div>parsing =
compressed files like something.el.gz but unfortunately the<br>reference in=
side the generated TAGS file uses the name "something.el"<br>inst=
ead of the complete file name "something.el.gz".=C2=A0 The same i=
s true<br>for the other compressed files (.bz2, .xz and .lzma).<br><br>When=
trying to use the etags xref back-end to move point to a definition<br><di=
v>inside such a file, the xref-find-definitions command will fail because t=
he</div><div> TAGS file identifies the .el file instead of the .el.gz file.=
</div><div><br></div>xref-find-definitions fails because it only checks if =
the uncompressed<br><div>file exists, it does not try to see if the compres=
sed file exists.</div><div></div><br>The issue is inside etags.el xref-loca=
tion-marker method.<br><br>The current code is:<br><br>(cl-defmethod xref-l=
ocation-marker ((l xref-etags-location))<br>=C2=A0 (with-slots (tag-info fi=
le) l<br>=C2=A0 =C2=A0 (let ((buffer (find-file-noselect file)))<br>=C2=A0 =
=C2=A0 =C2=A0 (with-current-buffer buffer<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (s=
ave-excursion<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (etags-goto-tag-locatio=
n tag-info)<br><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (point-marker))))))<=
/div><div><br></div><div><div>One could consider that the issue is inside t=
he etags utility.</div><div><br></div><div>An alternative would be to provi=
de Emacs with the ability to check <br></div><div>for the presence of the .=
el file and if it is not present look for the <br></div><div>equivalent com=
pressed files.</div></div><br>Here's a proposal for a solution:<br><br>=
<br>(defun etags-file-or-compressed-file-for (fname)<br>=C2=A0 "Return=
the valid file name for FNAME.<br>Check if FNAME is an existing file name,=
if not<br>try FNAME appended with the following compression extensions:<br=
>- \".gz\", the extension of compressed files created by gzip<br>=
- \".bz2\", the extension for compressed files created by bzip2<b=
r>- \".xz\", the extension for compressed files created by xz<br>=
- \".lzma\", the extension for compressed files created by xz.<br=
><br>Return the file that exists or nil if nothing found."<br>=C2=A0 (=
let ((fpath nil))<br>=C2=A0 =C2=A0 (cl-dolist (ext '(""<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 ".gz"<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 ".bz2"<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ".xz"<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
;.lzma"))<br>=C2=A0 =C2=A0 =C2=A0 (setq fpath (concat fname ext))<br>=
=C2=A0 =C2=A0 =C2=A0 (when (file-exists-p fpath)<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 (cl-return fpath)))))<br><br>(cl-defmethod xref-location-marker ((l =
xref-etags-location))<br>=C2=A0 (with-slots (tag-info file) l<br>=C2=A0 =C2=
=A0 (let (buffer<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (fname (pel-file-or-=
compressed-file-for file)))<br>=C2=A0 =C2=A0 =C2=A0 (if fname<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 (setq buffer (find-file-noselect fname))<br>=C2=A0=
=C2=A0 =C2=A0 =C2=A0 (user-error "file %s (or .gz, .bz2, .xz, .lzma) =
does not exist" file))<br>=C2=A0 =C2=A0 =C2=A0 (with-current-buffer bu=
ffer<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (save-excursion<br>=C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 (etags-goto-tag-location tag-info)<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 (point-marker))))))<br><div><br></div><div>------------------=
------------ END OF DESCRIPTION ] --------------------------------<br></div=
><div><br></div><div><br></div>In GNU Emacs 26.3 (build 1, x86_64-apple-dar=
win18.6.0)<br>=C2=A0of 2019-08-30 built on Mojave.local<br>Recent messages:=
<br>For information about GNU Emacs and the GNU system, type C-h C-a.<br><b=
r>Configured using:<br>=C2=A0'configure --disable-dependency-tracking -=
-disable-silent-rules<br>=C2=A0--enable-locallisppath=3D/usr/local/share/em=
acs/site-lisp<br>=C2=A0--infodir=3D/usr/local/Cellar/emacs/26.3/share/info/=
emacs<br>=C2=A0--prefix=3D/usr/local/Cellar/emacs/26.3 --with-gnutls --with=
out-x<br>=C2=A0--with-xml2 --without-dbus --with-modules --without-ns<br>=
=C2=A0--without-imagemagick'<br><br>Configured features:<br>NOTIFY ACL =
GNUTLS LIBXML2 ZLIB MODULES THREADS<br><br>Important settings:<br>=C2=A0 va=
lue of $LANG: en_CA.UTF-8<br>=C2=A0 locale-coding-system: utf-8-unix<br><br=
>Major mode: Lisp Interaction<br><br>Minor modes in effect:<br>=C2=A0 toolt=
ip-mode: t<br>=C2=A0 global-eldoc-mode: t<br>=C2=A0 eldoc-mode: t<br>=C2=A0=
electric-indent-mode: t<br>=C2=A0 menu-bar-mode: t<br>=C2=A0 file-name-sha=
dow-mode: t<br>=C2=A0 global-font-lock-mode: t<br>=C2=A0 font-lock-mode: t<=
br>=C2=A0 auto-composition-mode: t<br>=C2=A0 auto-encryption-mode: t<br>=C2=
=A0 auto-compression-mode: t<br>=C2=A0 line-number-mode: t<br>=C2=A0 transi=
ent-mark-mode: t<br><br>Load-path shadows:<br>None found.<br><br>Features:<=
br>(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv<br>byte=
comp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs<br>format-s=
pec rfc822 mml easymenu mml-sec password-cache epa derived epg<br>epg-confi=
g gnus-util rmail tool-bar rmail-loaddefs mm-decode mm-bodies<br>mm-encode =
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail<br>regexp-opt r=
fc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils<br>term/xterm xterm=
time-date elec-pair mule-util tooltip eldoc electric<br>uniquify ediff-hoo=
k vc-hooks lisp-float-type tabulated-list replace<br>newcomment text-mode e=
lisp-mode lisp-mode prog-mode register page<br>menu-bar rfn-eshadow isearch=
timer select mouse jit-lock font-lock<br>syntax facemenu font-core term/tt=
y-colors frame cl-generic cham georgian<br>utf-8-lang misc-lang vietnamese =
tibetan thai tai-viet lao korean<br>japanese eucjp-ms cp51932 hebrew greek =
romanian slovak czech european<br>ethiopic indian cyrillic chinese composit=
e charscript charprop<br>case-table epa-hook jka-cmpr-hook help simple abbr=
ev obarray minibuffer<br>cl-preloaded nadvice loaddefs button faces cus-fac=
e macroexp files<br>text-properties overlay sha1 md5 base64 format env code=
-pages mule<br>custom widget hashtable-print-readable backquote threads kqu=
eue<br>multi-tty make-network-process emacs)<br><br>Memory information:<br>=
((conses 16 96177 5831)<br>=C2=A0(symbols 48 19813 1)<br>=C2=A0(miscs 40 33=
96)<br>=C2=A0(strings 32 28253 1011)<br>=C2=A0(string-bytes 1 748198)<br>=
=C2=A0(vectors 16 11977)<br>=C2=A0(vector-slots 8 455846 6474)<br>=C2=A0(fl=
oats 8 48 566)<br>=C2=A0(intervals 56 197 0)<br><div>=C2=A0(buffers 992 11)=
)</div><div><br></div><div>;; ---------------------------</div><div><br></d=
iv><div>Thank you,</div><div><br></div><div>/Pierre Rouleau<br></div></div>
--0000000000002b5d5505b3787e54--
Pierre Rouleau <prouleau001@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#44494; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.