all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* X-coding-system incompatibility, and workaround
@ 2007-11-09 19:07 Tim Hesterberg
  2007-11-10  3:00 ` Richard Stallman
  0 siblings, 1 reply; 7+ messages in thread
From: Tim Hesterberg @ 2007-11-09 19:07 UTC (permalink / raw)
  To: bug-gnu-emacs

This report is primarily for your information.  I've found a problem,
and have a couple of workarounds, one of which can go in my .emacs.
However, at the end I have some thoughts on how new versions of emacs
might change to prevent other people from having the problem.

--------------------------------------------------

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.  There is an
error message
	Invalid coding system: us-ascii-unix

After that rmail doesn't work correctly on that file.  For some
messages, what is visible in my buffer is the raw rmail file,
including all headers and the message separator (which appears as
^_^L).  Other messages appear fine (sometimes; other times I can't
use the rmail file until I close and reopen it).

If I have an RMAIL Summary window open, and I scroll through messages
in either window (using "n"), the cursor doesn't move in the summary window
when the new message shows the headers, but does jump to the correct
spot when a "good" message appears.  (At least, that is the behavior
I'm getting now - other times I've run into the problem it seems that
after a problem occurs then typing "n" in the summary window does nothing.)

This occurs when a message has a header such as:
X-Coding-System: us-ascii-unix

On rare occasions other coding systems cause the same problem, e.g.
X-Coding-System: windows-1252-unix

--------------------------------------------------

I have two workarounds:
(1) Edit the rmail file (as an ordinary text file) and change
every instance of us-ascii-unix to iso-safe-unix.  Then I can read
the file using rmail and everything works.

This is motivated by (list-coding-systems), which on 22.1.1 has:
- -- iso-safe (alias: us-ascii)
  Encode ASCII asis and encode non-ASCII characters to `?'.
but on 21.3.1 has the iso-safe entry but with no alias.
	
Curiously, the rmail file has many instances of us-ascii; it does not
appear necessary to change these, only the small number of us-ascii-unix
entries.

(2) In 21.3.1, run:
(define-coding-system-alias 'us-ascii 'iso-safe)
After that I can read the unedited rmail file.

--------------------------------------------------

Suggestion:
Could you modify future versions of emacs to try to avoid using
coding systems that are not defined on earlier versions?
In this case, if 22.1.1 would use iso-safe-unix instead of us-ascii-unix
when creating rmail files, then I wouldn't have the problem reading
the files using 23.1.1.



--------------------------------------------------

In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
 of 2007-06-02 on RELEASE
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/gnuwin32/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: RMAIL

Minor modes in effect:
  display-time-mode: t
  shell-dirtrack-mode: t
  show-paren-mode: t
  encoded-kbd-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: X-coding-system incompatibility, and workaround
  2007-11-09 19:07 X-coding-system incompatibility, and workaround Tim Hesterberg
@ 2007-11-10  3:00 ` Richard Stallman
  2007-11-10 11:25   ` Eli Zaretskii
  2007-11-12 22:43   ` Tim Hesterberg
  0 siblings, 2 replies; 7+ messages in thread
From: Richard Stallman @ 2007-11-10  3:00 UTC (permalink / raw)
  To: Tim Hesterberg; +Cc: emacs-devel

    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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: X-coding-system incompatibility, and workaround
  2007-11-10  3:00 ` Richard Stallman
@ 2007-11-10 11:25   ` Eli Zaretskii
  2007-11-11  5:21     ` Richard Stallman
  2007-11-12 23:00     ` Tim Hesterberg
  2007-11-12 22:43   ` Tim Hesterberg
  1 sibling, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2007-11-10 11:25 UTC (permalink / raw)
  To: rms; +Cc: timh, emacs-devel

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: X-coding-system incompatibility, and workaround
  2007-11-10 11:25   ` Eli Zaretskii
@ 2007-11-11  5:21     ` Richard Stallman
  2007-11-12 23:00     ` Tim Hesterberg
  1 sibling, 0 replies; 7+ messages in thread
From: Richard Stallman @ 2007-11-11  5:21 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: timh, emacs-devel

    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?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: X-coding-system incompatibility, and workaround
  2007-11-10  3:00 ` Richard Stallman
  2007-11-10 11:25   ` Eli Zaretskii
@ 2007-11-12 22:43   ` Tim Hesterberg
  1 sibling, 0 replies; 7+ messages in thread
From: Tim Hesterberg @ 2007-11-12 22:43 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: X-coding-system incompatibility, and workaround
  2007-11-10 11:25   ` Eli Zaretskii
  2007-11-11  5:21     ` Richard Stallman
@ 2007-11-12 23:00     ` Tim Hesterberg
  2007-11-13 20:02       ` Richard Stallman
  1 sibling, 1 reply; 7+ messages in thread
From: Tim Hesterberg @ 2007-11-12 23:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rms, emacs-devel

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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: X-coding-system incompatibility, and workaround
  2007-11-12 23:00     ` Tim Hesterberg
@ 2007-11-13 20:02       ` Richard Stallman
  0 siblings, 0 replies; 7+ messages in thread
From: Richard Stallman @ 2007-11-13 20:02 UTC (permalink / raw)
  To: Tim Hesterberg; +Cc: eliz, emacs-devel

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2007-11-13 20:02 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-09 19:07 X-coding-system incompatibility, and workaround Tim Hesterberg
2007-11-10  3:00 ` Richard Stallman
2007-11-10 11:25   ` Eli Zaretskii
2007-11-11  5:21     ` Richard Stallman
2007-11-12 23:00     ` Tim Hesterberg
2007-11-13 20:02       ` Richard Stallman
2007-11-12 22:43   ` Tim Hesterberg

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.