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

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Let me try to answer: I don't know how it really works, but IIUC as long as
 > we only get ASCII bytes without end of line, the coding system is left as
 > `undecided' and on the first packet we receive with an LF or CR or a byte
 > larger than 128, the coding system is decided based on this packet and this
 > packet only.  Tho, I guess the decision on EOL is orthogonal, so we may go
 > from `undecided' to `undecided-unix' on one packet (or to `latin-undecided')
 > and only get to `latin1-unix' on a later packet.

Could be, although I really wouldn't want to make a decision based on
a very few non-ASCII bytes.  Point is, there has to be a buffer
holding that packet that the coding system has access to.  Perhaps
even an Emacs buffer in binary coding system or buffer-as-unibyte
mode.  It is analyzed and then the process seeks back to where the
non-ASCII stuff started (or, more likely, the beginning of the
buffer), and decodes it.  Then further input is read.

The same thing can surely be done with magic numbers to identify
images, zipfiles, and the like.  There is no need to open, close, and
reopen the stream, and none of the inefficiency that Eli was claiming.
The exception is if you're going to process it through an external
process (such as /bin/gzip) anyway, in which case the detection phase
is pretty small overhead compared to the convenience of doing the
detection in Emacs.