Re: jka-compr.el doesn't recognise gzipped files from their magic bytes

["Stephen J. Turnbull" <stephen@xemacs.org>]

Kenichi Handa writes:

 > Sorry, I have not followed this thread.  Could someone
 > please explain how CCL is related here?

I'm drawing an analogy between (1) looking at a text stream (process
or file) with autodetection, then decoding the text accroding to the
detected coding system, and (2) looking at the magic in a file, and
decoding it according to that magic.  The example of (2) discussed
here is a gzipped stream.  The problem to solve is that jka-compr
doesn't recognize such a stream unless it's a file with a name with
.gz extension.

Eli claims that looking at magic and then decoding the file would
necessarily introduce a lot of overhead, and I say that that is not
true, because it's not true for autodetected coding systems.

I also claim that for coding that can be implemented inside of Emacs,
the coding system framework could be adapted to this (or perhaps even
used directly, Ben Wing has demonstrated this in XEmacs with zlib, but
XEmacs is a quite different implementation from current Emacs).

The point about CCL is simply that a CCL coding system is completely
separate from the detector, and so must work on buffered input.  You
have to be able to seek to the beginning of the input stream and then
translate it.