Re: X-coding-system incompatibility, and workaround

Re: X-coding-system incompatibility, and workaround

[Richard Stallman]

    When I create an rmail file using emacs 22.1.1, then read the
    file using emacs 21.3.1 (on another system), it generally works, but
    occasionally I'll run into a message causes a problem.

Can you provide a copy of a file that causes this problem?
(Please uuencode it before you send it.)

Can you post a *precise* test case for this bug?  The test case should
start with `emacs -q', so that your .emacs file does not affect it,
and it should show exactly what text to put in the buffer, what
commands to execute, so as to produce such a file.

    Could you modify future versions of emacs to try to avoid using
    coding systems that are not defined on earlier versions?

I don't know if this is possible.  To think about the question
we would need to figure out WHY it uses those coding systems.
That's why we need a test case, etc.

Please read the Bugs section in the Emacs manual, which provides
guidelines on how to write a bug report to give us the
necessary information so we can fix the bug.

Re: X-coding-system incompatibility, and workaround

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 09 Nov 2007 22:00:11 -0500
> Cc: emacs-devel@gnu.org
> 
>     Could you modify future versions of emacs to try to avoid using
>     coding systems that are not defined on earlier versions?
> 
> I don't know if this is possible.  To think about the question
> we would need to figure out WHY it uses those coding systems.

Rmail uses these coding systems because the Babyl mail file requests
them in the X-coding-system header.  This header is generated by Rmail
when it decodes the mail message for the first time.  Thus, the value
of the header is very tightly coupled with which coding-systems are
supported by Emacs that produced the Babyl file.

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).

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.

Btw, for windows-1252-unix, you need to make it an alias to Latin-1.

Re: X-coding-system incompatibility, and workaround

[Richard Stallman]

    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).

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?

Re: X-coding-system incompatibility, and workaround

[Tim Hesterberg]

[-- Attachment #1: Type: text/plain, Size: 6383 bytes --]

Sorry, I should have included an example file.
Attached is an RMAIL file "bugReport".  This was created on 
GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600) of 2007-06-02 on RELEASE
I have this saved in ~/mail/bugReport on my system.
I'll give some output of uuencode below, as well.

To reproduce
On another system, I start an older version of emacs using emacs -q
this version is:
GNU Emacs 21.3.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars) of 2005-02-04 on porky.build.redhat.com
(I get the same symptoms at home, running Windows and emacs 21.3.1.)

On this system I do C-u M-x rmail
Emacs prompts for the file, and I specify ~/mail/bugReport

This results in the error message, and the following in the *Messages* buffer:
rmail-show-message: Invalid coding system: us-ascii-unix

Here's the bugReport file in uuencode format:

qalnx3201.153% uuencode bugReport bugReport.uuencode
begin 755 bugReport.uuencode
M0D%"64P@3U!424].4SH@+2HM(')M86EL("TJ+0T*5F5R<VEO;CH@-0T*3&%B
M96QS.@T*3F]T93H@("!4:&ES(&ES('1H92!H96%D97(@;V8@86X@<FUA:6P@
M9FEL92X-"DYO=&4Z("`@268@>6]U(&%R92!S965I;F<@:70@:6X@<FUA:6PL
M#0I.;W1E.B`@("!I="!M96%N<R!T:&4@9FEL92!H87,@;F\@;65S<V%G97,@
M:6X@:70N#0H?#`T*,2P@961I=&5D+"P-"E@M0V]D:6YG+5-Y<W1E;3H@=6YD
M96-I9&5D+75N:7@-"DUA:6PM9G)O;3H@1G)O;2!T:6UH0&EN<VEG:'1F=6PN
M8V]M($UO;B!.;W8@,3(@,30Z,C8Z-3,@,C`P-PT*1&%T93H@5&AU+"`R-2!/
M8W0@,C`P-R`Q,#HT-3HU-"`M,#<P,`T*1G)O;3H@5&EM($AE<W1E<F)E<F<@
M/'1I;6A`:6YS:6=H=&9U;"YC;VT^#0I4;SH@(G-O;65O;F4B(#QS;VUE;VYE
M0&EN<VEG:'1F=6PN8V]M/@T*4W5B:F5C=#H@4F4Z($5U<F]P93\-"@T**BHJ
M($5/3T@@*BHJ#0I$871E.B!4:'4L(#(U($]C="`R,#`W(#$P.C0U.C4T("TP
M-S`P#0I&<F]M.B!4:6T@2&5S=&5R8F5R9R`\=&EM:$!I;G-I9VAT9G5L+F-O
M;3X-"E1O.B`B<V]M96]N92(@/'-O;65O;F5`:6YS:6=H=&9U;"YC;VT^#0I3
M=6)J96-T.B!293H@175R;W!E/PT*#0I4:&ES(&ES(&UE<W-A9V4@,2X@($YO
M<FUA;"!T97AT(&1E;&5T960N#0I4:&ES(&ES(&UE<W-A9V4@,2X@($YO<FUA
M;"!T97AT(&1E;&5T960N#0I4:&ES(&ES(&UE<W-A9V4@,2X@($YO<FUA;"!T
M97AT(&1E;&5T960N#0I4:&ES(&ES(&UE<W-A9V4@,2X@($YO<FUA;"!T97AT
M(&1E;&5T960N#0I4:&ES(&ES(&UE<W-A9V4@,2X@($YO<FUA;"!T97AT(&1E
M;&5T960N#0I4:&ES(&ES(&UE<W-A9V4@,2X@($YO<FUA;"!T97AT(&1E;&5T
M960N#0H?#`T*,"P@961I=&5D+"!D971A8VAE9"PL#0HJ*BH@14]/2"`J*BH-
M"E@M0V]D:6YG+5-Y<W1E;3H@=7,M87-C:6DM=6YI>`T*36%I;"UF<F]M.B!&
M<F]M('-O;65O;F5`:6YS:6=H=&9U;"YC;VT@36]N($YO=B`Q,B`Q-#HR-CHU
M-B`R,#`W#0I-24U%+59E<G-I;VXZ(#$N,`T*0V]N=&5N="UT>7!E.B!T97AT
M+W!L86EN.PT*"6-H87)S970](G5S+6%S8VEI(@T*4W5B:F5C=#H@175R;W!E
M/PT*1&%T93H@5&AU+"`R-2!/8W0@,C`P-R`P.3HU,#HU,R`M,#<P,`T*1G)O
M;3H@(G-O;65O;F4B(#QS;VUE;VYE0&EN<VEG:'1F=6PN8V]M/@T*5&\Z(")4
M:6T@2&5S=&5R8F5R9R(@/'1I;6A`:6YS:6=H=&9U;"YC;VT^#0H-"E1H:7,@
M:7,@;65S<V%G92`R+B`@3F]R;6%L('1E>'0@9&5L971E9"X-"E1H:7,@:7,@
M;65S<V%G92`R+B`@3F]R;6%L('1E>'0@9&5L971E9"X-"E1H:7,@:7,@;65S
M<V%G92`R+B`@3F]R;6%L('1E>'0@9&5L971E9"X-"E1H:7,@=7-E<R!T:&4@
M9')E861E9"!U<RUA<V-I:2UU;FEX+@T*5&AI<R!I<R!M97-S86=E(#(N("!.
M;W)M86P@=&5X="!D96QE=&5D+@T*5&AI<R!I<R!M97-S86=E(#(N("!.;W)M
M86P@=&5X="!D96QE=&5D+@T*5&AI<R!I<R!M97-S86=E(#(N("!.;W)M86P@
M=&5X="!D96QE=&5D+@T*'PP-"C$L(&5D:71E9"PL#0I8+4-O9&EN9RU3>7-T
M96TZ('5S+6%S8VEI+75N:7@-"DUA:6PM9G)O;3H@1G)O;2!S;VUE;VYE0&EN
M<VEG:'1F=6PN8V]M($UO;B!.;W8@,3(@,30Z,C8Z-3<@,C`P-PT*34E-12U6
M97)S:6]N.B`Q+C`-"D-O;G1E;G0M='EP93H@=&5X="]P;&%I;CL-"@EC:&%R
M<V5T/2)U<RUA<V-I:2(-"E-U8FIE8W0Z(%)%.B!%=7)O<&4_#0I$871E.B!4
M:'4L(#(U($]C="`R,#`W(#$P.C4X.C(W("TP-S`P#0I&<F]M.B`B<V]M96]N
M92(@/'-O;65O;F5`:6YS:6=H=&9U;"YC;VT^#0I4;SH@(E1I;2!(97-T97)B
M97)G(B`\=&EM:$!I;G-I9VAT9G5L+F-O;3X-"@T**BHJ($5/3T@@*BHJ#0I3
M=6)J96-T.B!213H@175R;W!E/PT*1&%T93H@5&AU+"`R-2!/8W0@,C`P-R`Q
M,#HU.#HR-R`M,#<P,`T*1G)O;3H@(G-O;65O;F4B(#QS;VUE;VYE0&EN<VEG
M:'1F=6PN8V]M/@T*5&\Z(")4:6T@2&5S=&5R8F5R9R(@/'1I;6A`:6YS:6=H
M=&9U;"YC;VT^#0H-"E1H:7,@:7,@;65S<V%G92`S+B`@3F]R;6%L('1E>'0@
M9&5L971E9"X-"E1H:7,@:7,@;65S<V%G92`S+B`@3F]R;6%L('1E>'0@9&5L
M971E9"X-"E1H:7,@:7,@;65S<V%G92`S+B`@3F]R;6%L('1E>'0@9&5L971E
M9"X-"E1H:7,@=7-E<R!T:&4@9')E861E9"!U<RUA<V-I:2UU;FEX+@T*5&AI
M<R!I<R!M97-S86=E(#,N("!.;W)M86P@=&5X="!D96QE=&5D+@T*5&AI<R!I
M<R!M97-S86=E(#,N("!.;W)M86P@=&5X="!D96QE=&5D+@T*5&AI<R!I<R!M
M97-S86=E(#,N("!.;W)M86P@=&5X="!D96QE=&5D+@T*'PP-"C$L(&5D:71E
M9"PL#0I8+4-O9&EN9RU3>7-T96TZ('5S+6%S8VEI+75N:7@-"DUA:6PM9G)O
M;3H@1G)O;2!M:6YA<F1I0&EN<VEG:'1F=6PN8V]M($UO;B!.;W8@,3(@,30Z
M,C8Z-3D@,C`P-PT*34E-12U697)S:6]N.B`Q+C`-"D-O;G1E;G0M='EP93H@
M=&5X="]P;&%I;CL-"@EC:&%R<V5T/2)U<RUA<V-I:2(-"E-U8FIE8W0Z(%)%
M.B!4:71L92!O9B!B;V]T<W1R87`@8V]U<G-E#0I$871E.B!&<FDL(#(V($]C
M="`R,#`W(#`X.C`X.C0W("TP-S`P#0I&<F]M.B`B<V]M96]N945L<V4B(#QS
M;VUE;VYE16QS94!I;G-I9VAT9G5L+F-O;3X-"E1O.B`B<V]M96]N92(@/'-O
M;65O;F5`:6YS:6=H=&9U;"YC;VT^+`T*"2)4:6T@2&5S=&5R8F5R9R(@/'1I
M;6A`:6YS:6=H=&9U;"YC;VT^#0H-"BHJ*B!%3T](("HJ*@T*4W5B:F5C=#H@
M4D4Z(%1I=&QE(&]F(&)O;W1S=')A<"!C;W5R<V4-"D1A=&4Z($9R:2P@,C8@
M3V-T(#(P,#<@,#@Z,#@Z-#<@+3`W,#`-"D9R;VTZ(")S;VUE;VYE16QS92(@
M/'-O;65O;F5%;'-E0&EN<VEG:'1F=6PN8V]M/@T*5&\Z(")S;VUE;VYE(B`\
M<V]M96]N94!I;G-I9VAT9G5L+F-O;3XL#0H)(E1I;2!(97-T97)B97)G(B`\
M=&EM:$!I;G-I9VAT9G5L+F-O;3X-"@T*5&AI<R!I<R!M97-S86=E(#0N("!.
M;W)M86P@=&5X="!D96QE=&5D+@T*5&AI<R!I<R!M97-S86=E(#0N("!.;W)M
M86P@=&5X="!D96QE=&5D+@T*5&AI<R!I<R!M97-S86=E(#0N("!.;W)M86P@
M=&5X="!D96QE=&5D+@T*5&AI<R!U<V5S('1H92!D<F5A9&5D('5S+6%S8VEI
M+75N:7@N#0I4:&ES(&ES(&UE<W-A9V4@-"X@($YO<FUA;"!T97AT(&1E;&5T
M960N#0I4:&ES(&ES(&UE<W-A9V4@-"X@($YO<FUA;"!T97AT(&1E;&5T960N
M#0I4:&ES(&ES(&UE<W-A9V4@-"X@($YO<FUA;"!T97AT(&1E;&5T960N#0H?
`
end
qalnx3201.154% ls bug*


>    When I create an rmail file using emacs 22.1.1, then read the
>    file using emacs 21.3.1 (on another system), it generally works, but
>    occasionally I'll run into a message causes a problem.
>
>Can you provide a copy of a file that causes this problem?
>(Please uuencode it before you send it.)
>
>Can you post a *precise* test case for this bug?  The test case should
>start with `emacs -q', so that your .emacs file does not affect it,
>and it should show exactly what text to put in the buffer, what
>commands to execute, so as to produce such a file.
>
>    Could you modify future versions of emacs to try to avoid using
>    coding systems that are not defined on earlier versions?
>
>I don't know if this is possible.  To think about the question
>we would need to figure out WHY it uses those coding systems.
>That's why we need a test case, etc.
>
>Please read the Bugs section in the Emacs manual, which provides
>guidelines on how to write a bug report to give us the
>necessary information so we can fix the bug.

[-- Attachment #2: bugReport --]
[-- Type: application/octet-stream, Size: 3195 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: X-coding-system incompatibility, and workaround

[Tim Hesterberg]

Here are responses to parts of email from Eli Zaretskii <eliz@gnu.org> and 
Richard Stallman <rms@gnu.org>

>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.

Re: X-coding-system incompatibility, and workaround

[Richard Stallman]

    >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.

That's as good as we can hope for, I think.