From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pierre Rouleau Newsgroups: gmane.emacs.bugs Subject: bug#44494: etags.el xref-location-marker does not handle TAGS references to .el.gz files Date: Sat, 7 Nov 2020 09:15:12 -0500 Message-ID: References: <1cdac9f7-8340-83eb-f619-583e028e6e23@yandex.ru> <83wnyx7g0u.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c0ef4705b384f582" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32753"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44494@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 07 15:16:14 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kbP0n-0008O7-DN for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 07 Nov 2020 15:16:13 +0100 Original-Received: from localhost ([::1]:48900 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kbP0l-0001Qr-S8 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 07 Nov 2020 09:16:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37330) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kbP0d-0001Qi-7d for bug-gnu-emacs@gnu.org; Sat, 07 Nov 2020 09:16:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46604) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kbP0c-0007t3-7E for bug-gnu-emacs@gnu.org; Sat, 07 Nov 2020 09:16:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kbP0c-0006v5-2R for bug-gnu-emacs@gnu.org; Sat, 07 Nov 2020 09:16:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pierre Rouleau Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Nov 2020 14:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44494 X-GNU-PR-Package: emacs Original-Received: via spool by 44494-submit@debbugs.gnu.org id=B44494.160475853226557 (code B ref 44494); Sat, 07 Nov 2020 14:16:02 +0000 Original-Received: (at 44494) by debbugs.gnu.org; 7 Nov 2020 14:15:32 +0000 Original-Received: from localhost ([127.0.0.1]:58150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kbP07-0006uH-Ci for submit@debbugs.gnu.org; Sat, 07 Nov 2020 09:15:32 -0500 Original-Received: from mail-lf1-f50.google.com ([209.85.167.50]:34644) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kbP05-0006u3-Ov for 44494@debbugs.gnu.org; Sat, 07 Nov 2020 09:15:30 -0500 Original-Received: by mail-lf1-f50.google.com with SMTP id i6so5956329lfd.1 for <44494@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) In-Reply-To: <83wnyx7g0u.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:192833 Archived-At: --000000000000c0ef4705b384f582 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 7, 2020 at 3:00 AM Eli Zaretskii wrote: > > From: Pierre Rouleau > > Date: Fri, 6 Nov 2020 22:31:02 -0500 > > Cc: 44494@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
On Sat, Nov 7, 2020 at 3:00 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Pierre Rouleau <prouleau001@gmail.com>
> Date: Fri, 6 Nov 2020 22:31:02 -0500
> Cc: 44494@d= ebbugs.gnu.org
>
>=C2=A0 Do you see the same problem with 'M-x find-tag'?
>
> Short answer:=C2=A0 yes
>
> Longer answer:=C2=A0 you can try it on Emacs lib files.=C2=A0
>
> 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-byteco= mp.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: =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-byteco= mp.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.=C2=A0 Which doesn'= t
surprise me, since etags.el already has code that handles compressed
files.

Moreover, M-. (which uses xref) works as well.=C2=A0 So I'm no longer s= ure
I understand what is the problem you are seeing.=C2=A0 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:

=C2=A0 . "make TAGS" in the top-level directory of the Emacs sour= ce tree
=C2=A0 . gzip lisp/abbrevs.el
=C2=A0 . emacs -Q
=C2=A0 . C-x C-f lisp/simple.el
=C2=A0 . C-u M-. kill-all-abbrevs RET

And for find-tag, replace the last 2 commands with

=C2=A0 . M-x visit-tags-table RET RET
=C2=A0 . M-x find-tag RET kill-all-abbrevs RET

Both of these work and show abbrevs.el.gz at the correct line.
=C2=A0
Hi,=C2=A0 I did try your test, both on emac= s 26.3 and 27.1,
and for the exact scenario you described, it wo= rks if you search for kill-all-abbrevs.

I shou= ld have better describe the failure scenario.=C2=A0
- Proble= m=C2=A0 occurs in emacs 26.3 and 27.1.
- I search for cc-require = ,=C2=A0 a defmacro, not a defun, and not something
=C2=A0 that is= already loaded.
- on my system all files emacs/lisp director= y are .el.gz file, however,
=C2=A0 I do not think that the f= act they are all compressed is significant.

With b= oth 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> messag= e: No definitions found for cc-require

At this poi= nt:
- the xref backend is the default for .el files; etags.
=
- xref-backend-functions is set to (elisp--xref-backend t), a local se= tting.
- the abbrev feature is loaded, as M-: (featurep 'abbr= ev) returns t.
- So looking for kill-all-abbrevs using the elisp-= -xref-backend works, my
=C2=A0 understanding is that it work= s because the file that holds the definition
=C2=A0 is loade= d.

I wanted to be able to access definitions f= rom code that might not have
already been loaded so I thought I = would use the etags--xref-backend instead.

With em= acs 26.3 and 27.1 with all lisp/simple files compressed,
=C2=A0I = do (and get approximately same results, shown below):
. emacs -Q<= /div>
. 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 and hit RET
- 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\
es/cc-b= ytecomp.el
- 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

If I look in= side the TAGS file and search for cc-require,
I see it listed un= der the cc-bytecomp.el file.=C2=A0

If at this= point, I load the 2 functions I wrote and try again,
it suc= ceeds in finding cc-require.

To recap you need to = try searching for something that is not already
loaded and u= se 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--