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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2807 in the body.
You can then email your comments to 2807 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: MON KEY <monkey <at> sandpframing.com>
To: emacs-pretest-bug <at> gnu.org
Subject: Subject: 23.0.90; etags can't access .el.gz files
Date: Fri, 27 Mar 2009 23:39:58 -0400

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

Message #10 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: MON KEY <monkey <at> sandpframing.com>
Cc: 2807 <at> debbugs.gnu.org
Subject: Re: Subject: 23.0.90; etags can't access .el.gz files
Date: Mon, 12 Sep 2011 00:14:18 +0200

MON KEY <monkey <at> 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/

Message #15 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Francesco Potortì <pot <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: MON KEY <monkey <at> sandpframing.com>, 2807 <at> debbugs.gnu.org
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Tue, 13 Sep 2011 13:51:01 +0200

>MON KEY <monkey <at> 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.

Message #18 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Francesco Potortì <pot <at> gnu.org>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, MON KEY <monkey <at> sandpframing.com>,
	2807 <at> debbugs.gnu.org
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Tue, 13 Sep 2011 14:09:49 -0400

> 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

Message #21 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Francesco Potortì <pot <at> gnu.org>
Cc: MON KEY <monkey <at> sandpframing.com>, 2807 <at> debbugs.gnu.org
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Tue, 13 Sep 2011 20:24:36 +0200

Francesco Potortì <pot <at> 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/

Message #24 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Francesco Potortì <pot <at> gnu.org>,
	MON KEY <monkey <at> sandpframing.com>, 2807 <at> debbugs.gnu.org
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Fri, 07 Oct 2011 00:05:58 +0200

Stefan Monnier <monnier <at> 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/

Message #27 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: Francesco Potortì <pot <at> gnu.org>,
	MON KEY <monkey <at> sandpframing.com>, 2807 <at> debbugs.gnu.org
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Thu, 06 Oct 2011 21:52:29 -0400

>>> 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

Message #30 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Francesco Potortì <pot <at> gnu.org>,
	MON KEY <monkey <at> sandpframing.com>, 2807 <at> debbugs.gnu.org
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Fri, 07 Oct 2011 12:25:07 +0200

Stefan Monnier <monnier <at> 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/

Message #33 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: Francesco Potortì <pot <at> gnu.org>,
	MON KEY <monkey <at> sandpframing.com>, 2807 <at> debbugs.gnu.org
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Fri, 07 Oct 2011 09:29:06 -0400

>>> (".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

Message #36 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: MON KEY <monkey <at> sandpframing.com>, 2807 <at> debbugs.gnu.org
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Fri, 07 Oct 2011 16:38:01 +0200

Stefan Monnier <monnier <at> 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 <at> 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/

Message #41 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: 2807 <at> debbugs.gnu.org, 44494 <at> debbugs.gnu.org
Cc: pot <at> gnu.org, MON KEY <monkey <at> sandpframing.com>, prouleau001 <at> gmail.com,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, dgutov <at> yandex.ru,
 Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Thu, 12 Oct 2023 09:39:19 -0300

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 <at> 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

Message #44 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Mauro Aranda <maurooaranda <at> gmail.com>, 2807 <at> debbugs.gnu.org,
 44494 <at> debbugs.gnu.org
Cc: pot <at> gnu.org, MON KEY <monkey <at> sandpframing.com>, prouleau001 <at> gmail.com,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Thu, 12 Oct 2023 15:44:54 +0300

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.

Message #47 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: 2807 <at> debbugs.gnu.org, 44494 <at> debbugs.gnu.org
Cc: pot <at> gnu.org, MON KEY <monkey <at> sandpframing.com>, prouleau001 <at> gmail.com,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, dgutov <at> yandex.ru,
 Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Thu, 12 Oct 2023 09:46:52 -0300

[Message part 1 (text/plain, inline)]

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.

[0001-Fix-searching-for-tags-in-compressed-files.patch (text/x-patch, attachment)]

Message #52 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>, 2807 <at> debbugs.gnu.org,
 44494 <at> debbugs.gnu.org
Cc: pot <at> gnu.org, MON KEY <monkey <at> sandpframing.com>, prouleau001 <at> gmail.com,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Thu, 12 Oct 2023 09:51:09 -0300

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.

Message #55 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: pot <at> gnu.org, MON KEY <monkey <at> sandpframing.com>, 2807 <at> debbugs.gnu.org,
 prouleau001 <at> gmail.com, 44494 <at> debbugs.gnu.org, dgutov <at> yandex.ru,
 Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Thu, 12 Oct 2023 10:28:26 -0400

> +(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

Message #58 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: pot <at> gnu.org, 2807 <at> debbugs.gnu.org, prouleau001 <at> gmail.com,
 44494 <at> debbugs.gnu.org, dgutov <at> yandex.ru, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Thu, 12 Oct 2023 12:04:47 -0300

[Message part 1 (text/plain, inline)]

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.

[0001-Fix-searching-for-tags-in-compressed-files.patch (text/x-patch, attachment)]

Message #61 received at 2807 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Mauro Aranda <maurooaranda <at> gmail.com>, 2807 <at> debbugs.gnu.org,
 44494 <at> debbugs.gnu.org
Cc: pot <at> gnu.org, MON KEY <monkey <at> sandpframing.com>, prouleau001 <at> gmail.com,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Thu, 12 Oct 2023 18:47:48 +0300

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.

Message #66 received at 2807-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: pot <at> gnu.org, 44494-done <at> debbugs.gnu.org, prouleau001 <at> gmail.com,
 2807-done <at> debbugs.gnu.org, dgutov <at> yandex.ru,
 Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Sun, 15 Oct 2023 00:12:46 -0400

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.