Re: X-coding-system incompatibility, and workaround

[Tim Hesterberg]

Here are responses to parts of email from Eli Zaretskii <address@hidden> and 
Richard Stallman <address@hidden>

>I don't see how this can be solved: as Emacs is developed, support for
>new encodings is added to it, and it doesn't make sense to limit such
>development for a marginal situation such as this one (sharing the
>same mail file between two different versions of Emacs).

That is reasonable.

>As a workaround, I can suggest to run unrmail on the Babyl file in the
>Emacs that wrote it, and then run Rmail on the result in the other
>version of Emacs (that is, share the mail file in the mbox format).
>That is, if the workarounds the OP already discovered (which are
>perfectly valid, btw) are inconvenient for some reason.

The unrmail solution would not be convenient; I need to read the
mail files when the original system is not available.

The solution I'm using is convenient; I put lines like this into .emacs:
        (define-coding-system-alias 'us-ascii 'iso-safe)

>    I don't see how this can be solved: ...
>I agree.  However, the old version of Rmail fails in a rather nasty way
>when it encounters the unknown coding system.  Maybe it could fail
>more gently.
>
>Of course, we cannot fix the old version, but we could fix the version
>in Emacs 22.2 (if it still has the same problem) so it will fail more
>gently with future new coding systems.
>
>Would someone please look at this, then ack?

This appears to be fixed in emacs 22.1.1.
I created a copy of bugReport (see my previous message on this thread
an rmail file with some instances of us-ascii-unix encoding), and
changed all instances of us-ascii-unix to us-nonsense-unix (in headers
and elsewhere).  I then opened the new file using rmail; it opened
with no error messages, and I could scroll normally between messages
(using e.g. rmail-next-undeleted-message), and rmail-summary also seemed
to work fine.