Re: why unrmail fails with raw-text on version 22 [WAS: Re: help needed with coding systems (unrmail problems)]

[Mark Lillibridge <mark.lillibridge@hp.com>]

Eli wrote:
>  I (Mark) wrote:
>  > Not obvious, but important: with-temp-buffer creates a multibyte buffer
>  > so that insert-file-contents is decoding from raw-text to a multibyte
>  > buffer, producing raw 8-bit bytes for x80-xff.
>  
>  But doesn't insert-file-contents make the buffer unibyte due to the
>  fact that raw-text is being used for decoding?

    I looked again at the source code of unrmail, and it does not call
insert-file-contents with visit set, hence the buffer still being
multibyte.  If the author had done so and also specified replace (see
your excerpted source code fragment), presumably the buffer would have
been converted to unibyte.  There would still have been a bug because
the author also had code to convert to multibyte before doing decoding.


>  Version 22 is no longer maintained, so providing patches for it would
>  be pointless, especially as Emacs 23 has fundamentally changed the way
>  raw bytes are represented and handled.

Ok.


>  Emacs 23.3 is in pretest, so if you hurry, you could get the fix into
>  it (and into all the later versions).

    Building a fix for version 23 is trickier.  We need to decode the
output of version 22's raw-text into the new buffer internal
representation.  Can we use emacs-mule for this purpose?  Is it true
that decoding an arbitrary byte stream and then writing it out via
emacs-mule (version 23) produces exactly the same byte sequence?

- Mark