GNU bug report logs -
#2807
Subject: 23.0.90; etags can't access .el.gz files
Previous Next
Reported by: MON KEY <monkey <at> sandpframing.com>
Date: Sat, 28 Mar 2009 03:45:02 UTC
Severity: normal
Tags: confirmed, patch
Merged with 44494
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
Full log
Message #33 received at 2807 <at> debbugs.gnu.org (full text, mbox):
>>> (".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
This bug report was last modified 1 year and 219 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.