bug#2807: Subject: 23.0.90; etags can't access .el.gz files

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[MON KEY]

in dir /usr/share/emacs/23.0.90/lisp
M-x shell:
bash-3.1$ etags ./*.el.gz

when true:
(equal tags-file-name "/usr/share/emacs/23.0.90/lisp/TAGS")

M-x tags-search
tags-search

I get this error:
`next-file: Opening input file: no such file or directory,
/usr/share/emacs/23.0.90/lisp/abbrev.el'

When all *.el.gz are uncompressed there isn't a problem :)
However if any of the .el files are *.el.gz i get the error.

Can tags open the (now) default .el.gz files in ~emacs/*/lisp/

Shouldn't emacs decompress these files automatically on the fly?
;;; ==============================
In GNU Emacs 23.0.90.2 (i486-slackware-linux-gnu, GTK+ Version 2.12.12)
 of 2009-02-26 on slaptop
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
configured using `configure  '--prefix=/usr' '--sysconfdir=/etc'
'--localstatedir=/var' '--program-prefix=' '--program-suffix='
'--mandir=/usr/man' '--infodir=/usr/info' '--enable-static=no'
'--enable-shared=yes' '--with-x' '--with-x-toolkit=gtk'
'--build=i486-slackware-linux' 'build_alias=i486-slackware-linux'
'CFLAGS=-O2 -march=i486 -mtune=i686''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  show-paren-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Lars Magne Ingebrigtsen]

MON KEY <monkey@sandpframing.com> writes:

> in dir /usr/share/emacs/23.0.90/lisp
> M-x shell:
> bash-3.1$ etags ./*.el.gz
>
> when true:
> (equal tags-file-name "/usr/share/emacs/23.0.90/lisp/TAGS")
>
> M-x tags-search
> tags-search
>
> I get this error:
> `next-file: Opening input file: no such file or directory,
> /usr/share/emacs/23.0.90/lisp/abbrev.el'

I can confirm that this bug is still present in Emacs 24.

The problem is simply that etags puts the non-gz file name in the TAGS
file.  Like this:

font-core.el,502

Which means that Emacs isn't able to find the font-core.el.gz file.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Francesco Potortì]

>MON KEY <monkey@sandpframing.com> writes:
>
>> in dir /usr/share/emacs/23.0.90/lisp
>> M-x shell:
>> bash-3.1$ etags ./*.el.gz
>>
>> when true:
>> (equal tags-file-name "/usr/share/emacs/23.0.90/lisp/TAGS")
>>
>> M-x tags-search
>> tags-search
>>
>> I get this error:
>> `next-file: Opening input file: no such file or directory,
>> /usr/share/emacs/23.0.90/lisp/abbrev.el'
>
>I can confirm that this bug is still present in Emacs 24.
>
>The problem is simply that etags puts the non-gz file name in the TAGS
>file.  Like this:
>
>font-core.el,502
>
>Which means that Emacs isn't able to find the font-core.el.gz file.

Etags manages compressed files so that the generated TAGS file contains
the uncompressed file name, independently of whether the file on disk is
compressed or not.

The rationale for this behaviour is that the TAGS file does not contain
info about the compression status of a file.  This makes sense in the
case that when you use an editor you either have an uncompressed file on
disk or your editor is capable of finding the compressed version given
the uncompressed name.

I seem to remember that in past times Emacs was able to do that when
jka-compr was loaded, but I may be wrong.  I think that the solution
should be that etags.el cares about looking for possible compressed
versions of file names contained in TAGS file.

By the way, the xz compressor should be added to the list of known
compressors in etags.c, and the doc strings, man page and info updated
accordingly.

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Stefan Monnier]

> I seem to remember that in past times Emacs was able to do that when
> jka-compr was loaded, but I may be wrong.

IIRC the unbundled version of jka-compr included such a feature, but not
the one bundled with Emacs.

> I think that the solution should be that etags.el cares about looking
> for possible compressed versions of file names contained in TAGS file.

Please share the code with info.el which does that for its files.


        Stefan

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Lars Magne Ingebrigtsen]

Francesco Potortì <pot@gnu.org> writes:

> Etags manages compressed files so that the generated TAGS file contains
> the uncompressed file name, independently of whether the file on disk is
> compressed or not.

If etags just put the real file name (i.e., foo.el.gz) into the TAGS
file, then Emacs would do the right thing automatically.

But having etags.el look for compressed versions of the files
automatically would probably be even nicer.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I think that the solution should be that etags.el cares about looking
>> for possible compressed versions of file names contained in TAGS file.
>
> Please share the code with info.el which does that for its files.

Are you thinking of this bit?

(defvar Info-suffix-list
  ;; The MS-DOS list should work both when long file names are
  ;; supported (Windows 9X), and when only 8+3 file names are available.
  (if (eq system-type 'ms-dos)
      '( (".gz"       . "gunzip")
	 (".z"        . "gunzip")

[...]

    '( (".info.Z"    . "uncompress")
       (".info.Y"    . "unyabba")
       (".info.gz"   . "gunzip")
       (".info.z"    . "gunzip")
       (".info.bz2"  . ("bzip2" "-dc"))
       (".info.xz"   . "unxz")
       (".info"      . nil)
       ("-info.Z"    . "uncompress")
       ("-info.Y"    . "unyabba")

etc etc etc.  Is this even necessary in Info?  Doesn't jka-compr know
all about this already?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Stefan Monnier]

>>> I think that the solution should be that etags.el cares about looking
>>> for possible compressed versions of file names contained in TAGS file.
>> Please share the code with info.el which does that for its files.
> Are you thinking of this bit?
> (defvar Info-suffix-list
>   ;; The MS-DOS list should work both when long file names are
>   ;; supported (Windows 9X), and when only 8+3 file names are available.
>   (if (eq system-type 'ms-dos)
>       '( (".gz"       . "gunzip")
> 	 (".z"        . "gunzip")

> [...]

>     '( (".info.Z"    . "uncompress")
>        (".info.Y"    . "unyabba")
>        (".info.gz"   . "gunzip")
>        (".info.z"    . "gunzip")
>        (".info.bz2"  . ("bzip2" "-dc"))
>        (".info.xz"   . "unxz")
>        (".info"      . nil)
>        ("-info.Z"    . "uncompress")
>        ("-info.Y"    . "unyabba")

Yes.

> etc etc etc.  Is this even necessary in Info?

It's just as necessary as it is for etags: without it, Info won't find
the compressed files.

> Doesn't jka-compr know all about this already?

jka-compr knows how to decompress the main ones, yes.  But not all of
them, and (more importantly) it doesn't know how to look for them.


        Stefan

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>        (".info.xz"   . "unxz")
>>        (".info"      . nil)
>>        ("-info.Z"    . "uncompress")
>>        ("-info.Y"    . "unyabba")
>
> Yes.
>
>> etc etc etc.  Is this even necessary in Info?
>
> It's just as necessary as it is for etags: without it, Info won't find
> the compressed files.
>
>> Doesn't jka-compr know all about this already?
>
> jka-compr knows how to decompress the main ones, yes.  But not all of
> them, and (more importantly) it doesn't know how to look for them.

Sorry; I was unclear.  I meant: Doesn't jka-compr know how to uncompress
all these files already?

And if not -- why not?

Finding the files is a different issue, and since the file name list
contains "info" in all the names, there isn't much potential for reuse
by etags.

So I would suggest writing some code in jka-compr that would allow
jka-compr to look for compressed files, too (given a regexp), and then
etags could use that, and info.el could be converted (after Emacs 24.1)
to use that, too.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Stefan Monnier]

>>> (".info.xz"   . "unxz")
>>> (".info"      . nil)
>>> ("-info.Z"    . "uncompress")
>>> ("-info.Y"    . "unyabba")
>> 
>> Yes.
>> 
>>> etc etc etc.  Is this even necessary in Info?
>> 
>> It's just as necessary as it is for etags: without it, Info won't find
>> the compressed files.
>> 
>>> Doesn't jka-compr know all about this already?
>> 
>> jka-compr knows how to decompress the main ones, yes.  But not all of
>> them, and (more importantly) it doesn't know how to look for them.

> Sorry; I was unclear.  I meant: Doesn't jka-compr know how to uncompress
> all these files already?

As I said it "knows how to decompress the main ones, yes".

> And if not -- why not?

It doesn't do all of them because ... I don't know why.  My guess is
that there's a subtle risk of jka-compr applying when it shouldn't, so
we prefer to only use it when we're pretty sure the name implies it is
a compressed file.

> Finding the files is a different issue, and since the file name list
> contains "info" in all the names, there isn't much potential for reuse
> by etags.

Wholesale reuse, no, indeed.  But the compression-extension part, yes.

> So I would suggest writing some code in jka-compr that would allow
> jka-compr to look for compressed files, too (given a regexp), and then
> etags could use that, and info.el could be converted (after Emacs 24.1)
> to use that, too.

That sounds right.


        Stefan

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> As I said it "knows how to decompress the main ones, yes".

If you remove all the duplicates, it boils down to this list:

       (".Z"         . "uncompress")
       (".Y"         . "unyabba")
       (".gz"        . "gunzip")
       (".z"         . "gunzip")
       (".bz2"       . ("bzip2" "-dc"))
       (".xz"        . "unxz")

The only one that jka-compr doesn't handle is "unyabba", which I've
never heard of.  Neither has Debian, apparently...

[larsi@stories /tmp]$ apt-cache search yabba

> It doesn't do all of them because ... I don't know why.  My guess is
> that there's a subtle risk of jka-compr applying when it shouldn't, so
> we prefer to only use it when we're pretty sure the name implies it is
> a compressed file.

My guess is that this is just stuff that somebody forgot to remove once
jka-compr was written.  :-)

>> So I would suggest writing some code in jka-compr that would allow
>> jka-compr to look for compressed files, too (given a regexp), and then
>> etags could use that, and info.el could be converted (after Emacs 24.1)
>> to use that, too.
>
> That sounds right.

Ok, I'll take a whack at adding the "search for compressed files"
functionality to jka-compr, and fixing etags.el by using that.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Mauro Aranda]

My way of reproducing Bug#2807 is:

In emacs repo directory:
make tags
make install
emacs -Q

M-x visit-tags-table RET /path/to/where/installed/TAGS/ended-up
M-x tags-search RET tags-search

While it doesn't error out with:
`next-file: Opening input file: no such file or directory,

It says: All files processed
without finding tags-search.

Checking messages I see:

Scanning file /usr/local/share/emacs/30.0.50/lisp/cus-start.el...
Scanning file /usr/local/share/emacs/30.0.50/lisp/international/emoji.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/fontset.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/isearch-x.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-brackets.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-category.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-combining.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-comment.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-confusable.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-decimal.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-decomposition.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-digit.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-lowercase.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-mirrored.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-name.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-numeric.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-old-name.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-special-lowercase.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-special-titlecase.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-special-uppercase.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-titlecase.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/uni-uppercase.el...
Scanning file /usr/local/share/emacs/30.0.50/lisp/international/utf-7.el...
Scanning file /usr/local/share/emacs/30.0.50/lisp/org/ox-ascii.el...
Scanning file /usr/local/share/emacs/30.0.50/lisp/org/ob-matlab.el...
Scanning file /usr/local/share/emacs/30.0.50/lisp/mail/blessmail.el...
Scanning file /usr/local/share/emacs/30.0.50/lisp/loadup.el...
Scanning file /usr/local/share/emacs/30.0.50/lisp/leim/quail/ZOZY.el...
Scanning file /usr/local/share/emacs/30.0.50/lisp/leim/ja-dic/ja-dic.el...
Scanning file 
/usr/local/share/emacs/30.0.50/lisp/international/eucjp-ms.el...

Which says it's not scanning every file.  And something is off. It
couldn't be scanning cus-start.el, because I only have cus-start.elc and
cus-start.el.gz in that directory.  It seems to me that it's scanning
cus-load.el, which is not byte-compiled.  I think that the behavior
change with regards to the OP reproducer is:

commit df1dbaf121703aebae83d2725b7aed8b961f2913
Author: Dmitry Gutov <dgutov@yandex.ru>
Date:   Fri Jul 30 14:58:25 2021 +0200

     Make fileloop skip missing files

     * lisp/fileloop.el (fileloop-next-file): If a file doesn't exist,
     skip to the next one (bug#44979).


For reproducing Bug#44494, I follow the same steps, but instead of
executing tags-search I do:
(require 'xref)
M-x xref-etags-mode
C-u M-. tags-search

And get:
user-error: Rerun etags: ‘^(defun tags-search ’ not found in 
/usr/local/share/emacs/30.0.50/lisp/progmodes/etags.el

bug#44494: bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Dmitry Gutov]

On 12/10/2023 15:39, Mauro Aranda wrote:
> For reproducing Bug#44494, I follow the same steps, but instead of
> executing tags-search I do:
> (require 'xref)
> M-x xref-etags-mode
> C-u M-. tags-search

tags-search is not an Xref command. So whether you load 'xref' and turn 
on xref-etags-mode, or not, should have no effect on how 'tags-search' 
works.

bug#44494: bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Mauro Aranda]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

tags 2807 patch
quit


I did some debugging, and while internally etags.el knows how to handle
compressed files, it doesn't pass good enough information to external
tools like fileloop (Bug#2807) and xref (Bug#44494).

I attach a patch to fix both bugs, Bug#2807 and Bug#44494.  It reuses
tags-compression-info-list to pass the correct filename to the tools
mentioned.

[-- Attachment #2: 0001-Fix-searching-for-tags-in-compressed-files.patch --]
[-- Type: text/x-patch, Size: 2279 bytes --]

From 8b7ca63475f4bffe98a962ff8c1f899fb1581aa8 Mon Sep 17 00:00:00 2001
From: Mauro Aranda <maurooaranda@gmail.com>
Date: Thu, 12 Oct 2023 09:41:58 -0300
Subject: [PATCH] Fix searching for tags in compressed files

* lisp/progmodes/etags.el (etags--ensure-file): New function.
(etags--all-files): Make sure files in TAGS can be visited, even if
the files are compressed.  (Bug#2807)
(etags--xref-find-definitions): Report to xref a file that we are sure
it exists.  (Bug#44494)
---
 lisp/progmodes/etags.el | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/lisp/progmodes/etags.el b/lisp/progmodes/etags.el
index cb95f29b5fe..6f9bdae81d3 100644
--- a/lisp/progmodes/etags.el
+++ b/lisp/progmodes/etags.el
@@ -1729,6 +1729,19 @@ tags-next-file
   (fileloop-next-file novisit)
   (switch-to-buffer (current-buffer)))
 
+(defun etags--ensure-file (file)
+  "Ensure FILE can be visited.
+
+FILE should be an expanded file name.
+This function tries to locate FILE, possibly adding it a suffix
+present in `tags-compression-info-list'.  If the file can't be found,
+signals an error.
+Else, returns the filename that can be visited for sure."
+  (let ((f (locate-file file nil tags-compression-info-list)))
+    (unless f
+      (signal 'file-missing (list "Cannot locate file in TAGS" file)))
+    f))
+
 (defun tags--all-files ()
   (save-excursion
     (let ((cbuf (current-buffer))
@@ -1750,7 +1763,7 @@ tags--all-files
           ;; list later returned by (tags-table-files).
           (setf (if tail (cdr tail) files)
                 (mapcar #'expand-file-name (tags-table-files)))))
-      files)))
+      (mapcar #'etags--ensure-file files))))
 
 (make-obsolete-variable 'tags-loop-operate 'fileloop-initialize "27.1")
 (defvar tags-loop-operate nil
@@ -2137,7 +2150,7 @@ etags--xref-find-definitions
               (beginning-of-line)
               (pcase-let* ((tag-info (etags-snarf-tag))
                            (`(,hint ,line . _) tag-info))
-                (let* ((file (file-of-tag))
+                (let* ((file (etags--ensure-file (file-of-tag)))
                        (mark-key (cons file line)))
                   (unless (gethash mark-key marks)
                     (let ((loc (xref-make-etags-location
-- 
2.34.1

bug#44494: bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Mauro Aranda]

On 12/10/23 09:44, Dmitry Gutov wrote:
 > On 12/10/2023 15:39, Mauro Aranda wrote:
 >> For reproducing Bug#44494, I follow the same steps, but instead of
 >> executing tags-search I do:
 >> (require 'xref)
 >> M-x xref-etags-mode
 >> C-u M-. tags-search
 >
 > tags-search is not an Xref command. So whether you load 'xref' and 
turn on xref-etags-mode, or not, should have no effect on how 
'tags-search' works.

I'm not running tags-search in recipe for Bug#44494.  I'm asking
xref-find-definitions (M-.) to find the definition of tags-search.

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> +(defun etags--ensure-file (file)
> +  "Ensure FILE can be visited.
> +
> +FILE should be an expanded file name.
> +This function tries to locate FILE, possibly adding it a suffix
> +present in `tags-compression-info-list'.  If the file can't be found,
> +signals an error.
> +Else, returns the filename that can be visited for sure."
> +  (let ((f (locate-file file nil tags-compression-info-list)))
> +    (unless f
> +      (signal 'file-missing (list "Cannot locate file in TAGS" file)))
> +    f))

The patch looks pretty good, but other parts of the code use
check `auto-compression-mode` before using `tags-compression-info-list`,
so we should probably do the same here.

As other comments mention in the file, this arrangement is suboptimal
because the search for compressed filenames should probably be moved to
jka-compr's code (e.g. using `jka-compr-compression-info-list` rather
than `tags-compression-info-list`).

Historical side note: jka-compr used to have the ability to do what we
want here "transparently" (it changed things like `find-file-noselect`
to look for compressed versions of the file, among other things).
IIRC it was removed when it got integrated into Emacs (don't know why
but I assumed it was too hackish/ugly/costly/brittle).

We should arguably re-add this feature, tho maybe not transparent,
i.e. let packages who need that request that feature explicitly (like
here).


        Stefan

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Mauro Aranda]

[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

On 12/10/23 11:28, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
 >> +(defun etags--ensure-file (file)
 >> +  "Ensure FILE can be visited.
 >> +
 >> +FILE should be an expanded file name.
 >> +This function tries to locate FILE, possibly adding it a suffix
 >> +present in `tags-compression-info-list'.  If the file can't be found,
 >> +signals an error.
 >> +Else, returns the filename that can be visited for sure."
 >> +  (let ((f (locate-file file nil tags-compression-info-list)))
 >> +    (unless f
 >> +      (signal 'file-missing (list "Cannot locate file in TAGS" file)))
 >> +    f))
 >
 > The patch looks pretty good, but other parts of the code use
 > check `auto-compression-mode` before using `tags-compression-info-list`,
 > so we should probably do the same here.

Thank you!  Yes, I should've added that check.  I attach a patch that
incorporates the check.

 > As other comments mention in the file, this arrangement is suboptimal
 > because the search for compressed filenames should probably be moved to
 > jka-compr's code (e.g. using `jka-compr-compression-info-list` rather
 > than `tags-compression-info-list`).

Yes, but I opted to go with this simpler patch for a 24 year-old bug
report.

 > Historical side note: jka-compr used to have the ability to do what we
 > want here "transparently" (it changed things like `find-file-noselect`
 > to look for compressed versions of the file, among other things).
 > IIRC it was removed when it got integrated into Emacs (don't know why
 > but I assumed it was too hackish/ugly/costly/brittle).
 >
 > We should arguably re-add this feature, tho maybe not transparent,
 > i.e. let packages who need that request that feature explicitly (like
 > here).
 >

That's good to know, thank you.  And I agree that the feature would be
good to have, but I hope that in the meantime we can go with the updated
patch.

[-- Attachment #2: 0001-Fix-searching-for-tags-in-compressed-files.patch --]
[-- Type: text/x-patch, Size: 2332 bytes --]

From bfed523e3ae8007e959e7801a3cbcd0a4c7b83d8 Mon Sep 17 00:00:00 2001
From: Mauro Aranda <maurooaranda@gmail.com>
Date: Thu, 12 Oct 2023 09:41:58 -0300
Subject: [PATCH] Fix searching for tags in compressed files

* lisp/progmodes/etags.el (etags--ensure-file): New function.
(etags--all-files): Make sure files in TAGS can be visited, even if
the files are compressed.  (Bug#2807)
(etags--xref-find-definitions): Report to xref a file that we are sure
it exists.  (Bug#44494)
---
 lisp/progmodes/etags.el | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/lisp/progmodes/etags.el b/lisp/progmodes/etags.el
index cb95f29b5fe..d48dcc6659d 100644
--- a/lisp/progmodes/etags.el
+++ b/lisp/progmodes/etags.el
@@ -1729,6 +1729,21 @@ tags-next-file
   (fileloop-next-file novisit)
   (switch-to-buffer (current-buffer)))
 
+(defun etags--ensure-file (file)
+  "Ensure FILE can be visited.
+
+FILE should be an expanded file name.
+This function tries to locate FILE, possibly adding it a suffix
+present in `tags-compression-info-list'.  If the file can't be found,
+signals an error.
+Else, returns the filename that can be visited for sure."
+  (let ((f (locate-file file nil (if auto-compression-mode
+				     tags-compression-info-list
+				   '("")))))
+    (unless f
+      (signal 'file-missing (list "Cannot locate file in TAGS" file)))
+    f))
+
 (defun tags--all-files ()
   (save-excursion
     (let ((cbuf (current-buffer))
@@ -1750,7 +1765,7 @@ tags--all-files
           ;; list later returned by (tags-table-files).
           (setf (if tail (cdr tail) files)
                 (mapcar #'expand-file-name (tags-table-files)))))
-      files)))
+      (mapcar #'etags--ensure-file files))))
 
 (make-obsolete-variable 'tags-loop-operate 'fileloop-initialize "27.1")
 (defvar tags-loop-operate nil
@@ -2137,7 +2152,7 @@ etags--xref-find-definitions
               (beginning-of-line)
               (pcase-let* ((tag-info (etags-snarf-tag))
                            (`(,hint ,line . _) tag-info))
-                (let* ((file (file-of-tag))
+                (let* ((file (etags--ensure-file (file-of-tag)))
                        (mark-key (cons file line)))
                   (unless (gethash mark-key marks)
                     (let ((loc (xref-make-etags-location
-- 
2.34.1

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Dmitry Gutov]

On 12/10/2023 15:51, Mauro Aranda wrote:
> I'm not running tags-search in recipe for Bug#44494.  I'm asking
> xref-find-definitions (M-.) to find the definition of tags-search.

Ah, thanks. Your latest patch looks good to me.

bug#2807: Subject: 23.0.90; etags can't access .el.gz files

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> That's good to know, thank you.  And I agree that the feature would be
> good to have, but I hope that in the meantime we can go with the updated
> patch.

Yes, of course, I pushed it to `master`, thanks.
Still hoping for Someone™ to try and move that code to jka-compr :-)


        Stefan