9:39 p.m.
[Reposted from comp.emacs.xemacs, with some cruft deleted and some
more information. -BAW]
I've been working on the internationalized version of Mailman
recently, and I wanted to test multibyte charset support
(e.g. Japanese), so I built a version of XEmacs 21.4.6 configured
--with-mule as the only configure option. This actually works really
great; I can coax Mailman 2.1a4+ to send me a Japanese password
reminder and I see lots of pretty characters in my VM windows. A
friend of mine who can read Japanese confirms that the messages say
what their supposed to say <wink>.
However, I've noticed one incompatibility so far. I have some files
which are encrypted with GnuPG 1.0.6. In the non-MULE version of
21.4.6 (i.e. built with no configure options), I can simply visit the
file, XEmacs prompts for the encryption key which I enter, and I'm
presented with the decrypted file in a buffer.
However, when configured with --with-mule, after entering the
encryption key, the decrypt fails and I'm left with this in the
buffer:
gpg: fatal: zlib inflate problem: incorrect data check^Msecmem usage: 2272/2432 bytes in
6/7 blocks of pool 2432/16384
(single character ^M replaced for transport)
Actually everything from the ^M onward is displayed as an elipsis.
I've confirmed that my recent updating of all packages is not the
cause because I rebuild from source without MULE and I can still
decrypt the file. It's definitely a breakage --with-mule.
Anybody have any ideas? Known bug? Googling didn't turn up much
useful, except a seemingly unrelated couple of messages in the gnupg
lists.
If it weren't for this, I'd probably use a MULE-ified XEmacs all the
time. It certainly helps for developing MM2.1 and it also makes all
that spam I get look much prettier. :)
FTR: RH6.1 (mostly), XEmacs 21.4.6, latest packages. I believe that
I'm using crypt.el from the standard, and current, os-utils package.
-------------------- snip snip --------------------
`find-file-hooks' is a variable declared in Lisp.
-- loaded from "/usr/local/src/xemacs-21.4.6/lisp/files.elc"
Value: (efs-set-buffer-mode crypt-find-file-hook vc-find-file-hook
font-lock-set-defaults)
Documentation:
List of functions to be called after a buffer is loaded from a file.
The buffer's local variables (if any) will have been processed before the
functions are called.
-------------------- snip snip --------------------
Thanks,
-Barry
3:12 a.m.
Barry A. Warsaw wrote:
However, I've noticed one incompatibility so far. I have some
files
which are encrypted with GnuPG 1.0.6. In the non-MULE version of
21.4.6 (i.e. built with no configure options), I can simply visit the
file, XEmacs prompts for the encryption key which I enter, and I'm
presented with the decrypted file in a buffer.
However, when configured with --with-mule, after entering the
encryption key, the decrypt fails and I'm left with this in the
buffer:
gpg: fatal: zlib inflate problem: incorrect data check^Msecmem usage: 2272/2432 bytes in
6/7 blocks of pool 2432/16384
(single character ^M replaced for transport)
Actually everything from the ^M onward is displayed as an elipsis.
I've confirmed that my recent updating of all packages is not the
cause because I rebuild from source without MULE and I can still
decrypt the file. It's definitely a breakage --with-mule.
Anybody have any ideas? Known bug? Googling didn't turn up much
useful, except a seemingly unrelated couple of messages in the gnupg
lists.
Presumably it's a file-coding problem, i.e. it still occurs if you use
--with-file-coding instead of --with-mule.
If so, whichever "auto-decode" package is involved (mailcrypt,
jka-compr, ...) should probably bind coding-system-for-read and/or
coding-system-for-write to 'binary.
Also, it can usually be worked around by the user by setting
process-coding-system-alist, e.g.
(push '("/.*" . binary) process-coding-system-alist)
--
Glynn Clements <glynn.clements(a)virgin.net>
3:35 a.m.
Hi Glynn, thanks for the suggestions...
>>>> "GC" == Glynn Clements
<glynn.clements(a)virgin.net> writes:
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.
I also tried setting process-coding-system-alist as described, but
that didn't seem to do the trick either. Presumably the car is
supposed to match a program name, and I'm not sure if it's invoking gpg
via absolute path or relative path, so I tried this:
(push '(".*gpg" . binary) process-coding-system-alist)
This resulting in a different error:
gpg: packet with S2K 3 too short
Fun. ;)
-Barry
4:12 a.m.
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>
5:43 a.m.
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.
>>>> "GC" == Glynn Clements
<glynn.clements(a)virgin.net> writes:
GC> Yes; the fact that a process was involved led me to overlook
GC> the fact that a buffer is also involved.
GC> Does it work if you do "C-u C-x C-f ..." then answer
"binary"
GC> for the coding system?
Indeed, it does.
GC> By the time find-file-hook gets involved, it's probably too
GC> late. But if the decoding is triggered by the file's suffix,
GC> then changing file-coding-system-alist accordingly may work.
I'm happy enough to use the C-u work around.
Thanks,
-Barry
8086
days inactive
8113
days old
4 comments
3 participants
participants (3)
-
Barry A. Warsaw -
bwarsaw＠python.org -
Glynn Clements