From xemacs-m  Tue Jan 28 14:41:57 1997
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5])
          by xemacs.org (8.8.4/8.8.4) with SMTP
	  id OAA26940 for <xemacs-beta@xemacs.org>; Tue, 28 Jan 1997 14:41:56 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA19070; Tue, 28 Jan 1997 12:41:25 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id MAA18571; Tue, 28 Jan 1997 12:41:23 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA05430; Tue, 28 Jan 1997 12:41:23 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA04358; Tue, 28 Jan 1997 12:41:22 -0800
Date: Tue, 28 Jan 1997 12:41:22 -0800
Message-Id: <199701282041.MAA04358@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: drich@cisco.com, "Tomasz J. Cholewo" <tjchol01@mecca.spd.louisville.edu>
Cc: xemacs-beta@xemacs.org
Subject: Continued jka-compr problems 
In-Reply-To: <199701280208.SAA05179@sandman>
References: <199701280208.SAA05179@sandman>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.100)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Dan" == Dan Rich <drich@cisco.com> writes:

Dan> It looks like the patch I sent earlier doesn't quite fix the problem
Dan> (which will teach me to send in a patch before I have fully tested it).

One thing to keep in mind when you're dealing with front-ends to file
reading/writing commands:

When a file on disk is compressed, you want to run gunzip in such a
way that the no-conversion coding system is used on input to the
program, and the ``nornal'' coding system of the resulting filename
sans .gz extension is used to decode the output of gzip.

Similar considerations apply if sending the input of a buffer to an
external program.

I tried to fix this a little by adding '("\\.\\(gz\\|Z\\)$" . binary)
to file-coding-system-alist, but this is a half-fix, and a more
general solution is desirable in future.  I'd like to see how GNU
Emacs 19.35 will deal with this issue.  I believe they have an alist
of process names to input and output coding systems, which would allow
one to specify, for example, that gunzip would always use
no-conversion on input, but not necessarily on output, without
changing any lisp packages that call gunzip.  It's easy to find gaping
holes in this scheme, since``gzip'' gets used for both compression and
decompression, and the coding systems that are required depend on the
direction gzip is working.

Bottom line: jka-compr and similar utilies need some mule-izing to
truly work correctly.

Martin

