bwarsaw(a)python.org wrote:
GC> Presumably it's a file-coding problem, i.e. it still
occurs if
GC> you use --with-file-coding instead of --with-mule.
GC> If so, whichever "auto-decode" package is involved (mailcrypt,
GC> jka-compr, ...) should probably bind coding-system-for-read
GC> and/or coding-system-for-write to 'binary.
GC> Also, it can usually be worked around by the user by setting
GC> process-coding-system-alist, e.g.
GC> (push '("/.*" . binary) process-coding-system-alist)
My XEmacs-fu is bit rusty, and I'm not familar at all with the coding
system stuff, but I think we have a problem here.
I'm using crypt.el via crypt-find-file-hook in my find-file-hook to do
the auto decrypting. By the time crypt-find-file-hook gets into the
act, the file's already read into the buffer isn't it? So it's too
late to bind coding-system-for-read to catch this.
Yes; the fact that a process was involved led me to overlook the fact
that a buffer is also involved.
Does it work if you do "C-u C-x C-f ..." then answer "binary" for the
coding system?
By the time find-file-hook gets involved, it's probably too late. But
if the decoding is triggered by the file's suffix, then changing
file-coding-system-alist accordingly may work.
--
Glynn Clements <glynn.clements(a)virgin.net>