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

[Kenichi Handa]

In article <address@hidden>, "Stephen J. Turnbull" <address@hidden> writes:

> 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 think it's possible to implement what you want by
modifying Finsert_file_contents as this:

In the case of visiting a regular file, it reads the whole
file into an unibyte buffer, then calls set-auto-coding
(Lisp).  We can make it read the first 1K and the last 3K
bytes into an unibyte buffer and call set-auto-coding.  And
set-auto-coding can be modified to handle a magic head
(perhaps, if gzip-magic is found, replace the buffer with
gunzipped-data, and do the normal work of set-auto-coding).
Finsert_file_contents can know that the buffer already
contains a full data by checking if the buffer is modified
or not.

Anyway, my long term todo-list contains re-implementation of
insert-file-contents in Lisp, and change the current
Finsert_file_contents to do only a basic file reading (as in
Emacs 19).  Then we can improve insert-file-contents more
easily.

---
Kenichi Handa
address@hidden