From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Lars Magne Ingebrigtsen <larsi@gnus.org>
Cc: MON KEY <monkey@sandpframing.com>, 2807@debbugs.gnu.org
Subject: bug#2807: Subject: 23.0.90; etags can't access .el.gz files
Date: Fri, 07 Oct 2011 09:29:06 -0400 [thread overview]
Message-ID: <jwvsjn5hr0q.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <m3sjn5umik.fsf@stories.gnus.org> (Lars Magne Ingebrigtsen's message of "Fri, 07 Oct 2011 12:25:07 +0200")
>>> (".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
next prev parent reply other threads:[~2011-10-07 13:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-28 3:39 bug#2807: Subject: 23.0.90; etags can't access .el.gz files MON KEY
2011-09-11 22:14 ` Lars Magne Ingebrigtsen
2011-09-13 11:51 ` Francesco Potortì
2011-09-13 18:09 ` Stefan Monnier
2011-10-06 22:05 ` Lars Magne Ingebrigtsen
2011-10-07 1:52 ` Stefan Monnier
2011-10-07 10:25 ` Lars Magne Ingebrigtsen
2011-10-07 13:29 ` Stefan Monnier [this message]
2011-10-07 14:38 ` Lars Magne Ingebrigtsen
2011-09-13 18:24 ` Lars Magne Ingebrigtsen
2023-10-12 12:39 ` Mauro Aranda
2023-10-12 12:44 ` bug#44494: " Dmitry Gutov
2023-10-12 12:51 ` Mauro Aranda
2023-10-12 15:47 ` Dmitry Gutov
2023-10-12 12:46 ` bug#44494: " Mauro Aranda
2023-10-12 14:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-12 15:04 ` Mauro Aranda
2023-10-15 4:12 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvsjn5hr0q.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=2807@debbugs.gnu.org \
--cc=larsi@gnus.org \
--cc=monkey@sandpframing.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.