GNU bug report logs - #3452
23.0.94; display

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3452 in the body.
You can then email your comments to 3452 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.94; display
Date: Tue, 02 Jun 2009 22:53:14 -0400

Visiting the file foo.msg after emacs -Q in a 37-line Linux terminal
garbles the screen, including the mode line and menu bar.
I last updated the source on May 26.

begin 666 foo.msg
M6"U3<&%M+5-T871U<SH <at> 3F\L('-C;W)E/2TP+C4@<F5Q=6ER960]-2XP('1E
M<W1S/4%73"Q"05E%4U\P,"P*"49/4D=%1%]20U9$7TA%3$\L34E-15]"05-%
M-C1?3D]?3D%-12Q.3U]214%,7TY!344L"@E354)*14-47T5.0T]$141?5%=)
M0T4 <at> 875T;VQE87)N/6YO('9E<G-I;VX],RXQ+C`*1&%T93H <at> 5'5E+"`P,B!*
M=6X@,C`P.2`Q,CHQ,SHS."`K,#,P,`I4;SH <at> 96X@/&$M:6YF;W,M96Y`86EN
M9F]S+F-A/@I-97-S86=E+6ED.B`\-$$R-$5$-#(N-C`T,#0P.$!N971V:7-I
M;VXN;F5T+FEL/@I-24U%+79E<G-I;VXZ(#$N,`I&<F]M.B!A+6EN9F]S+65N
M0&%I;F9O<RYC80I3=6)J96-T.B`H96XI(#T_=71F+3 <at> _<3]#86QL7V9O<E]3
M=6UM97)?;V9?4F5S:7-T86YC93U%,CTX,#U!1%\]13(].#`]04,R,#\]"B`]
M/W5T9BTX/W$_,#D]13(].#`]040J7T-O;&QA<'-E7W1H95]S96-U<FET>5]A
M<F-H:71E8W1U<F5S/44R/3 <at> P/4%$(3\]"B`]/W5T9BTX/V(_-&]#<S\]"E)E
M<&QY+51O.B!A+6EN9F]S+65N0&%I;F9O<RYC80I#;VYT96YT+51Y<&4Z('1E
M>'0O<&QA:6X[(&-H87)S970](G5T9BTX(@H*"D%G86EN<W0 <at> 3D%43RP <at> 1S(P
M+"!'."P <at> 1G)O;G1E>"!A;F0@=&AE(.*`G%-T;V-K:&]L;2!0<F]G<F%M;67B
M@)TA("TM+2T <at> 4VEN8V4@=&AE(&5N9"!O9B!T:&4@"FQA<W0@;6EL;&5N;FEU
M;2!A(&UO9&EF:6-A=&EO;B!O9B!T:&7B@*T <at> XH"<XH"L<V5C=7)I='D <at> 87)C
M:&ET96-T=7)EXH"MXH"=(.*`K'=I=&AI;B!T:&4 <at> 154@=&%K97,@"G!L86-E
M+.*`K2#B@*QW:&EC:"!H879E(&)E96X <at> 86-C96QE<F%T960 <at> 8GD@=&AE(&%T
M=&%C:W,@;V;B@*T <at> XH"L,3$@XH"L4V5P=&5M8F5RXH"M(.*`K#(P,#'B@*T@
MXH"L:6X@=&AE(`I5;FET960 <at> 4W1A=&5S+N*`K2#B@*Q6:7-I8FQE('!H96YO
M;65N82!A<F4 <at> 9F]R(&5X86UP;&4@=&AE(&5N=&%N9VQE;65N="!O9B!I;G1E
M<FYA;"!A;F0@"F5X=&5R;F%L('-E8W5R:71Y+.*`K2#B@*QAXH"M(.*`G.*`
MK'!O;VQI;F?B@*WB@)T <at> XH"L;V8@<')O<V5C=71I;VX <at> 875T:&]R:71I97,@
M86YD(&EN=&5L;&EG96YC92!S979I8V5S(`IA;F0 <at> 82!S:6UP;&EF:65D(&1A
M=&$@97AC:&%N9V4N("`M+2TM(.*`K$%T('1H92!T96-H;FEC86P@;&5V96P@
M=V4 <at> 87)E(&-O;F9R;VYT960@=VET:"!N97<@"F1I9VET86P@<W5R=F5I;&QA
M;F-E(&-A;65R87,L(.*`K'-A=&5L;&ET92!S=7)V96EL;&%N8V4LXH"M(.*`
MK&)I;VUE=')I8W,LXH"M(.*`K&1R;VYE<RSB@*T <at> XH"L<V]F='=A<F4@"F9O
M<B!I;G1E;&QI9V5N="!S96%R8V@@:6X <at> 9&%T86)A<V5S(&%N9"!N97<@8G)O
M861B86YD(&YE='=O<FMS('1O(&UA;F%G92!T:&ES(&AU9V4 <at> 9FQO;V0@"F]F
M(&1I9VET86P <at> 9&%T82X@+2TM+2#B@*Q.97<@:6YS=&ET=71I;VYS(&%N9"!A
M=71H;W)I=&EE<R!H879E(&)E96X <at> 8W)E871E9"SB@*T <at> XH"L:6YC;'5D:6YG
M(`IT:&7B@*T <at> XH"<XH"L175R;W!E86X <at> 4&]L:6-E($]F9FEC92!%=7)O<&]L
M+.*`K2#B@*QT:&4@<&]L:6-E(&%C861E;7D <at> 0T503TPLXH"M(.*`K'1H92!B
M;W)D97(@86=E;F-Y(`I&<F]N=&5X(&%N9"!T:&7B@*WB@)T <at> XH"L0V]M;6ET
M=&5E(&9O<B!T:&4 <at> 36%N86=E;65N="!O9B!/<&5R871I;VYA;"!#;V]P97)A
M=&EO;N*`K2`B(.*`K&]F(&%L;"`*<&]L:6-E(&%G96YC:65S(&]F('1H92!%
M52!W:71H:6X@:71S(&EN=&5L;&EG96YC92!O<&5R871I;VX <at> 87-S97-S;65N
M="!C96YT97(N"N*`CB#B@(\*070@=&AE(&EN:71I871I=F4@;V8 <at> 9F]R;65R
M($9R96YC:"!$969E;G-E($UI;FES=&5RXH".("CB@(]A;F0 <at> 8W5R<F5N="!)
M;G1E<FEO<@I-:6YI<W1E<N*`K2D <at> XH"L36EC:,.H;&4 <at> 06QL:6]T+4UA<FEE
M('1H9>*`K2`BXH"L175R;W!E86X <at> 1V5N9&%R;65R:64 <at> 1F]R8V7B@*T@*.*`
MK$5'1N*`K2D <at> XH"L=V%S"F9O=6YD960 <at> 86YD(&AA<R!B965N(&5S=&%B;&ES
M:&5D(&ENXH"M(.*`K#(P,#0NXH"M(.*`K%1H92!%1T8@<VAA;&P <at> 96YS=7)E
M('1H9>*`K2#B@)SB@*QP=6)L:6,*;W)D97+B@*WB@)WB@*PLXH"M(.*`K&-O
M;6)A="!I;G-U<F=E;F-Y+.*`K2#B@*QO8G1A:6X@:6YT96QL:6=E;F-E(&EN
M9F]R;6%T:6]N(&%N9"!P<F]T96-T('!R;W!E<G1Y"FEN(&-O;F9L:6-T(&%R
M96%S+@H*5&AE('-E8W5R:71Y(&EN9'5S=')Y(&ES(&QI:V5L>2!O;F4@;V8@
M=&AE(&9E=R!B<F%N8VAE<R!T:&%T('!R;V9I=',@;6%S<VEV92!F<F]M('1H
M90IC=7)R96YT(&-R:7-I<R!O9B!C87!I=&%L:7-M(&%N9"!T:&4@<F5S=6QT
M:6YG(&)A='1L97,NXH"M"@KB@*Q%=7)O<&7B@)ES('!O;&EC92!F;W)C97,@
M87)E('!R97!A<FEN9R!T:&5M<V5L=F4 <at> 9F]R('!R;W1E<W0 <at> 86YD(')E<VES
M=&%N8V4 <at> 86=A:6YS=`IT:&4@:6UP86-T(&]F('1H92!C<FES:7,NXH"M(.*`
MK$5V96X@=&AE(&-H86ER;6%N(&]F('1H92!);G1E<FYA=&EO;F%L($UO;F5T
M87)Y($9U;F0 <at> 24U&"F%D;6ET<R!T:&%T(&EN(&9U='5R92!M;W)E(')I;W1S
M(&%R92!E>'!E8W1E9"[B@*T*XH"L5&AE(&EN<W1I='5T:6]N<R!O9B!T:&7B
M@*T <at> XH"<XH"L;&5A9&EN9R!E8V]N;VUI8R!N871I;VYSXH"MXH"=(.*`K&%R
M92!F;W)C960@=&\@<F4M;W)G86YI>F4*=&AE;7-E;'9E<R[B@*T <at> XH"L5&AE
MXH"M(.*`G.*`K'-U;6UI='/B@*WB@)T <at> XH"L;V8 <at> 3D%43RSB@*T <at> XH"L1SCB
M@*T <at> XH"L86YD($<R,.*`K2#B@*QA<F4@;V8 <at> 8V5N=')A;"!I;7!O<G1A;F-E
M"F9O<B!T:&ES(')E;W)G86YI>F%T:6]N+N*`K2#B@*Q4;W!I8W,@<W5C:"!A
M<R!C;&EM871E+.*`K2#B@*QM:6=R871I;VX <at> 86YD(&%G<FEC=6QT=7)E(&%R
M90IC;VYS:61E<F5D(&%S('1H<F5A="!T;R!T:&4@<V5C=7)I='D@;V8 <at> 8>*`
MK2#B@)SB@*QW97-T97)N(&QI9F5S='EL9>*`K>*`G>*`K"[B@*T*XH"L5VET
M:&EN('1H92!%=7)O<&5A;B!5;FEO;BSB@*T <at> XH"L9&]M97-T:6,@<&]L:71I
M8V%L(&-H86YG96UE;G1S(&%R92!T86MI;F<@<&QA8V4LXH"M"N*`K'=H;W-E
M(&5F9F5C=',@87)E(&-U<G)E;G1L>2!D:69F:6-U;'0@<')E9&EC="X*"D5V
M97)Y(&9I=F4@>65A<G,LXH"M(.*`K'1H92!I;G1E<FEO<B!A;F0@:G5S=&EC
M92!M:6YI<W1E<G,@;V8@=&AE(&YE=R!%52!A9&]P="!N97<*9&ER96-T:79E
M<R!F;W(@82!C;VUM;VX <at> 9&]M97-T:6,@<&]L:6-Y+N*`K2#B@*Q4:&7B@*T@
MXH"<XH"L5&%M<&5R92!0<F]G<F%MXH"MXH"=XH"L+.*`K2#B@*QT97)M:6YA
M=&5D"FENXH"M(.*`K#$Y.3GB@*T <at> XH"L=6YD97(@=&AE($9I;FYI<V@@4')E
M<VED96YC>2SB@*T <at> XH"L=V%S('!R:6UA<FEL>2!AXH"M(.*`G.*`K&UA;F%G
M96UE;G0@;V8*;6EG<F%T:6]N(&9L;W=SXH"MXH"=XH"L.N*`K2#B@*Q);B!A
M9&1I=&EO;B!T;R!T:&4 <at> 87!P<F5C:6%T:6]N(&]F('1H92!P;VQI8V4 <at> 875T
M:&]R:71Y($5U<F]P;VP*=V%S('1H92!E<W1A8FQI<VAM96YT(&]F(&'B@*T@
MXH"<XH"L5&%S:R!&;W)C92!O9B!%52!0;VQI8V4 <at> 0VAI969SXH"MXH"9XH"=
M(.*`K'=H:6-HXH"M(.*`K&1E86QS('=I=&CB@*T*XH"<XH"L:6YT97)N871I
M;VYA;"!T97)R;W)I<VWB@*WB@)T <at> XH"L86YDXH"M(.*`G.*`K'9I;VQE;G0@
M<&]L:71I8V%L(&%C=&EV:7-MXH"MXH"=XH"L+@H*5VET:"!T:&7B@*T <at> XH"<
MXH"L2&%G=64 <at> 4')O9W)A;>*`K>*`G2#B@*QI;N*`K2#B@*PR,#`T+.*`K2#B
M@*QI="!H87,@8F5E;B!A9W)E960@=7!O;B!T:&4 <at> 8W)E871I;VX@;V8 <at> 86[B
M@*T*XH"<XH"L87)E82!O9B!F<F5E9&]M+.*`K2#B@*QS96-U<FET>2!A;F0@
M:G5S=&EC9>*`K>*`G>*`K"[B@*T <at> XH"L06=A:6X@:70@=V%S(&1E8VED960@
M;VX*:6YT96YS:69I8V%T:6]N<R!O9B!M:6=R871I;VX@<&]L:6-Y+.*`K2#B
M@*QI;F-L=61I;F<@=&AE(&-O;G-T<G5C=&EO;B!O9B!";W)D97(@06=E;F-Y
MXH"M"N*`G.*`K$9R;VYT97CB@*WB@)T <at> XH"L86YD('1H92!I;G1E<F-E<'1I
M;VX@;V8@<F5F=6=E97,@86QR96%D>2!I;B!T:&5I<B!H;VUE(&-O=6YT<FEE
M<R[B@*T <at> XH"<XH"L5&AE"DAA9W5E(%!R;V=R86WB@*WB@)T <at> XH"L<'5T<R!T
M:&7B@*T <at> XH"<XH"L9&5F96YS92!O9B!T97)R;W)I<VWB@*WB@)T <at> XH"L:6X@
M=&AE(&-E;G1E<B[B@*T <at> XH"L070@=&AE(&QE=F5L(&]F"FEN9F]R;6%T:6]N
M(&5X8VAA;F=E(&%N9"!C;V]P97)A=&EO;B!W87,@;F]W(&-O=6YT(&]N('1H
M9>*`K2#B@)SB@*QP<FEN8VEP;&4@;V8*879A:6QA8FEL:71YXH"MXH"=XH"L
M+N*`K0KB@*Q4:&4 <at> 9W5I9&5L:6YE<R!O9N*`K2#B@*PR,#`TXH"M(.*`K&%R
M92!A;')E861Y(&EM<&QE;65N=&5D(&)Y(&UA;GD <at> 154@;65M8F5R('-T871E
M<SKB@*T*"E-T86YD87)D:7IA=&EO;B!O9B!T:&7B@*T <at> XH"<XH"L=&5R<F]R
M:7-MXH"MXH"=(.*`K&QE9VES;&%T:6]N+.*`K2#B@*QD871A(')E=&5N=&EO
M;BSB@*T <at> XH"L97AP86YS:6]N(&]F"F5X:7-T:6YG(&1A=&%B87-E<R!A;F0@
M<VAA<F5D(&%C8V5S<RSB@*T <at> XH"L8W)O<W,M8F]R9&5R('!O;&EC92!C;V]P
M97)A=&EO;B!F;W(@97AA;7!L90IA="!S<&]R=&EN9R!E=F5N=',@;W(@<&]L
M:71I8V%L(&UA<W,@<')O=&5S=',LXH"M(.*`G.*`K$)O<F1E<B!-86YA9V5M
M96YTXH"MXH"=XH"L+.*`K0KB@*QF:6YG97)P<FEN=',@=VAE;B!A<'!L:6-A
M=&EO;B!F;W(@154@=FES82SB@*T <at> XH"L9G)O;>*`K2#B@*PR,#`YXH"M(.*`
MK&YE=R!B:6]M971R:6,@:61E;G1I9FEE<G,*:6X@:61E;G1I='D <at> 9&]C=6UE
M;G1S+.*`K2#B@*QT:&4 <at> 9&5V96QO<&UE;G0@;V8@<V5C=7)I='D@<F5S96%R
M8V <at> LXH"M(.*`K&-O;W!E<F%T:6]N(&EN"F-R:6UI;F%L(&UA='1E<G,LXH"M
M(.*`K'!O;&EC92!A8G)O860 <at> 971C+@H*XH".(N*`CU1H92!(86=U92!0<F]G
M<F%MXH"M(B#B@*QI<R!R=6YN:6YG(&]U="!A;F0 <at> 82!N97<@<')O9W)A;2!S
M:&]U;&0 <at> 8F4 <at> 9&5C:61E9"!O;B!I;@IA=71U;6X@;V;B@*T <at> XH"L,C`P.2SB
M@*T <at> XH"L:6X <at> 4W1O8VMH;VQM('5N9&5R('1H92!3=V5D:7-H($55(%!R97-I
M9&5N8WDNXH"M"N*`K$1U<FEN9R!T:&4 <at> 1V5R;6%N($55(%!R97-I9&5N8WGB
M@*T <at> XH"L,C`P-RSB@*T <at> XH"L=&AE($=E<FUA;B!);G1E<FEO<B!-:6YI<W1E
M<B!7;VQF9V%N9PI38VC#I'5B;&4 <at> 8W)E871E9"!W:71H('1H92SB@*T <at> XH"L
M=&AE;B!%=7)O<&5A;B!#;VUM:7-S:6]N97(@9F]R($EN=&5R;F%L($%F9F%I
M<G/B@*T@*`KB@)SB@*Q*=7-T:6-E(&%N9"!(;VUE($%F9F%I<G/B@*WB@)TI
MXH"L+.*`K2#B@*Q&<F%N8V\@1G)A='1I;FDLXH"M(.*`K'1H9>*`K2#B@)SB
M@*Q&=71U<F4 <at> 1W)O=7#B@*WB@)WB@*PNXH"M(.*`K%1H:7/B@*T*XH"<XH"L
M1G5T=7)E($=R;W5PXH"MXH"=(.*`K&1E<V-R:6)E<R!I='-E;&8 <at> 87/B@*T@
MXH"<XH"L:6YF;W)M86P <at> 8F]D>>*`K>*`G2#B@*QO9B!%=7)O<&5A;B!I;G1E
M<FEO<@IM:6YI<W1E<G,LXH"M(.*`K'=H:6-H(&1R869T960 <at> 9W5I9&5L:6YE
M<R!F;W(@175R;W!E86X@:&]M92!A9F9A:7)S+N*`K0I4;R!A9&]P="!T:&4@
M;F5WXH"M(.*`G.*`K%-T;V-K:&]L;2!P<F]G<F%MXH"MXH"=XH"L+.*`K2#B
M@*QT:&7B@*T <at> XH"<XH"L1G5T=7)E($=R;W5PXH"MXH"=(.*`K'-U8FUI='1E
M9"!A"G=I<V <at> M;&ES="!F;W+B@*T@(N*`K'!O;&EC92!C;V]P97)A=&EO;BSB
M@*T <at> XH"L9FEG:'0 <at> 86=A:6YS="!T97)R;W)I<VTLXH"M(.*`K&UA;F%G96UE
M;G0@;V8*;6ES<VEO;G,@:6X@=&AI<F0 <at> 8V]U;G1R:65S+.*`K2#B@*QM:6=R
M871I;VXLXH"M(.*`K&%S>6QU;2!A;F0 <at> 8F]R9&5R(&UA;F%G96UE;G0LXH"M
M(.*`K&-I=FEL"G!R;W1E8W1I;VXLXH"M(.*`K&YE=R!T96-H;F]L;V=I97,@
M86YD(&EN9F]R;6%T:6]N(&YE='=O<FMSXH"M("+B@*PNXH"M(.*`K%!R:6]R
M:71I97,@87)E('1H90IM86EN=&5N86YC92!O9B!T:&7B@*T <at> XH"<XH"L175R
M;W!E86X@;6]D96SB@*WB@)WB@*PLXH"M(.*`G.*`K&-O<&EN9R!W:71H('1H
M92!G<F]W:6YG(&EN=&5R9&5P96YD96YC90IB971W965N(&EN=&5R;F%L(&%N
M9"!E>'1E<FYA;"!S96-U<FET>>*`K>*`G2#B@*QA;F0 <at> 96YS=7)I;F<@;V;B
M@*T <at> XH"<XH"L175R;W!E+7=I9&4@=&AE(&)E<W0*<&]S<VEB;&4 <at> 9&%T82!N
M971W;W)K<^*`K>*`G>*`K"X*"E1H92!M96%S=7)E<R!W:&EC:"!S:&%L;"!B
M92!D96-I9&5D(&EN(%-T;V-K:&]L;2!W:6QL(&]N;'D <at> 8F4@;F]T:6-E86)L
M92!B>2!T:&4*;65M8F5R('-T871E<R!W:71H:6X@:71S(')A=&EF:6-A=&EO
M;B!I;B!A(&9E=R!Y96%R<R[B@*T <at> XH"L5&AE<F4 <at> 87)E('!R;V9O=6YD(&-H
M86YG97,@:6X*=&AE(&=A;64ZXH"M"F1E=F5L;W!M96YT(&%N9"!S=&%N9&%R
M9&EZ871I;VX@;V8@<&]L:6-E(&1A=&%B87-E<RSB@*T <at> XH"L82!C96YT<F%L
M('!O<'5L871I;VX*<F5G:7-T97(LXH"M(.*`K")C<F]S<RUB;W)D97(@;VYL
M:6YE('-E87)C:.*`K2+B@*PL(&UO<F4 <at> 8V]N=')O;"!O9B!T:&4 <at> 26YT97)N
M970LXH"M(.*`K&)E='1E<@IS871E;&QI=&4@=')A8VMI;F<LXH"M(.*`K')I
M<VL <at> 86YA;'ES:7/B@*T <at> XH"<XH"L<V]F='=A<F4L(.*`K>*`G>*`K&4M8F]R
M9&5R<^*`K2(@XH"L86YDXH"M(.*`G.*`K&4M:G5S=&EC9>*`K>*`G>*`K"SB
M@*T*0V]M;6]N(&1E<&]R=&%T:6]N('!L86YE<R!A;F0 <at> 9FQI9VAT<RSB@*T@
MXH"L;F5W(')E9G5G964 <at> 8V%M<"!I;N*`K2#B@)SB@*QT:&ER9"!C;W5N=')I
M97/B@*WB@)WB@*PLXH"M"N*`K'1H92!U<V4@;V8@=&AE(&UI;&ET87)Y(&1E
M9F5N<V4@;V8@;6EG<F%T:6]N+.*`K2#B@*QM;W)E('!O;&EC92!I;G1E<G9E
M;G1I;VYS(&]U='-I9&4*=&AE($55+.*`K2#B@*QT:&4 <at> 97AP86YS:6]N(&]F
M('!A<F%M:6QI=&%R>>*`K2#B@)SB@*Q%=7)O<&5A;B!'96YD87)M97)I92!&
M;W)C9>*`K>*`G>*`K"SB@*T <at> XH"L;6]R90IC;V]P97)A=&EO;B!B971W965N
M(&1O;65S=&EC(&%N9"!F;W)E:6=N('-E8W)E="!S97)V:6-E<RSB@*T <at> XH"L
M971C+N*`K0H*5&AE(&%I;2!I<R!A(&MI;F0@;V8 <at> 9&]M97-T:6-A;$Y!5$\L
MXH".(.*`CW=I=&@@=&AE(&-R96%T:6]N(&]F(&'B@*T <at> XH"<XH"L175R;RU!
M=&QA;G1I8PIC;V]P97)A=&EO;B!I;B!T:&4 <at> 87)E82!O9B!F<F5E9&]M+.*`
MK2#B@*QS96-U<FET>2!A;F0@:G5S=&EC9>*`K>*`G2#B@*QF<F]MXH"M(.*`
MK#(P,30N"@I!;'-O('1H92!.051/(&%T=&%C:&5S('9A;'5E('1O('1H92!C
M96YT<F%L(')O;&4@;V8@=&AE($5U<F]P96%N(&1O;65S=&EC('!O;&ET:6-S
M+@I/;B!O;F4@:&%N9"SB@*T <at> XH"L;6]R92!A;F0@;6]R92!P;VQI8V4@;6ES
M<VEO;G,@:6[B@*T <at> XH"<XH"L=&AI<F0 <at> 8V]U;G1R:65SXH"MXH"=(.*`K'=E
M<F4@;&%U;F-H960LXH"M"N*`K'=H:6-H('!E<F9O<FT@=&AE<F4@=&%S:W,@
M;V8@=&AE(&UI;&ET87)Y+.*`K2#B@*QS=')I:V4 <at> 9&]W;B!L;V-A;"!U<')I
M<VEN9W,@86YD('1R86EN"FQO8V%L('!O;&EC92!U;FET<R[B@*T*3VX@=&AE
M(&]T:&5R(&AA;F0LXH"M(.*`K$Y!5$\M<W1R871E9VES=',@<&QA>2!T:&4@
M8F%L;"!B86-K('1O('1H92!%=7)O<&5A;B!I;G1E<FEO<@IM:6YI<W1E<G,@
M86YD(')E9F5R('1O('1H92!I;7!O<G1A;F-E(&]F($5U<F]P96%NXH"M(.*`
MG.*`K$AO;65L86YD(%-E8W5R:71YXH"MXH"=(.*`K'=I=&AO=70 <at> 8>*`K0KB
M@)SB@*QS=')O;F<@9&5F96YS9>*`K>*`G2#B@*QT;R!T:&4@;W5T<VED92!W
M;W5L9&[B@)ET(&)E('!O<W-I8FQE+N*`K2#B@*Q4:&4 <at> 3D%43R!S965S(&ET
M<V5L9 <at> IW:71H:6X@;65M8F5R(&-O=6YT<FEE<R!A<R!T:&4 <at> 9W5A<F%N=&]R
M(&]F('-E8W5R:71Y(&]FXH"M(.*`G.*`K&-R:71I8V%L(&EN9G)A<W1R=6-T
M=7)EXH"MXH"="BCB@*QL:6ME(&5N97)G>2SB@*T <at> XH"L=')A;G-P;W)T871I
M;VXLXH"M(.*`K&-O;6UU;FEC871I;V[B@*TIXH"L+N*`K0KB@*Q4:&4@<W1R
M871E9WD <at> 9&]C=6UE;G3B@*T <at> XH"<XH"L5&]W87)D<R!A($=R86YD(%-T<F%T
M96=Y(&9O<B!A;B!5;F-E<G1A:6X <at> 5V]R;&3B@*WB@)T <at> XH"L8GD <at> 9FEV90IE
M>"UG96YE<F%L<RSB@*T <at> XH"L=VAI8V@@87)E86YC:&]R960@:6X@=&AE(&1E
M9F5N<V4@:6YD=7-T<GDLXH"M(.*`K&-A;&QS(&9O<B!T:&4 <at> 97AP86YS:6]N
M"F]FXH"M(.*`G.*`K&-I=FEL+6UI;&ET87)Y(&-O;W!E<F%T:6]NXH"MXH"=
MXH"L+N*`K2#B@*Q#;VYS:61E<F5D(&%S(&'B@*T <at> XH"<XH"L8VEV:6QI86X@
M96QE;65N='/B@*WB@)T <at> XH"L87)E"F9O<B!E>&%M<&QE(%!O;&EC92SB@*T@
MXH"L:6YT96QL:6=E;F-E+.*`K2#B@*QR97-E87)C:"SB@*T <at> XH"L86-A9&5M
M:65S+.*`K2#B@*QC:79I;"!P<F]T96-T:6]N(&)U=`IA;'-O('1H92!P<FEV
M871E('-E8W5R:71Y(&EN9'5S=')Y+N*`K2#B@*Q.051/('=A;G1S('1O(&EN
M=&5N<VEF>2!T:&4 <at> 9F%L;"!B86-K(&]N('1H9>*`K0KB@)SB@*Q%=7)O<&5A
M;B!'96YD87)M97)I92!&;W)C9>*`K>*`G>*`K"[B@*T*XH"L5VET:"!T:&7B
M@*T <at> XH"<XH"L8VEV:6PM;6EL:71A<GD <at> 8V]O<&5R871I;V[B@*WB@)T <at> XH"L
M=&AE(&UI;&ET87)I>F%T:6]N(&]F('-O8VEA;"!C;VYF;&EC=',@:7,*:6YC
M<F5A<VEN9RSB@*T <at> XH"L=6YD97)P:6YN960 <at> 8GD <at> 9&]M97-T:6,@<&]L:71I
M8V%L(')E87)M86UE;G0 <at> 86YD(&YE=^*`K2(@XH"L86YT:2UT97)R;W+B@*T*
M(N*`K&QA=W,N"@I4:&4 <at> 9F]R;65R($55($-O;6UI<W-I;VYE<B!F;W(@2G5S
M=&EC92!A;F0 <at> 2&]M92!!9F9A:7)S+.*`K2#B@*Q&<F%N8V\@1G)A='1I;FDL
MXH"M(.*`K&AA<PIC:&%N9V5D(&EN($)E<FQU<V-O;FGB@)ES($-A8FEN970@
M869T97(@=&AE(&5L96-T:6]N<R!I;B!)=&%L>>*`K2#B@*PR,#`X+N*`K2#B
M@*Q!<R!T:&4@;F5W"F9O<F5I9VX@;6EN:7-T97(LXH"M(.*`K&AE(&ES(&YO
M=R!R97-P;VYS:6)L92!F;W(@=&AE($<XXH"M(.*`K&]N('1H92!387)D:6YI
M86X@:7-L86YD(&]F($QA"DUA9&1A;&5N82[B@*T <at> XH"L1G)A='1I;FD@<V5E
M<^*`K2#B@)SB@*QS96-U<FET>>*`K>*`G2#B@*QA<R!T:&4 <at> 8V5N=')A;"!P
M<F]F:6QE(&]F('1H92!N97<@1SCB@*T*XH"L<W1R=6-T=7)E<SKB@*T <at> XH"<
MXH"L175R;W!E(&-A;BSB@*T <at> XH"L<F%T:&5R('1H86X@:G5S="!A(&-O;G-U
M;65R+.*`K2#B@*QB92!A('!R;V1U8V5R(&]F"G-A9F5T>2[B@*T <at> XH"L0G5T
M($55(&%N9"!.051/(&YE960@=&\@:6YT96=R871E+.*`K2#B@*QR871H97(@
M=&\@:6YT97)F97)E('=I=&@@96%C:"!O=&AE<G,NXH"M"N*`K%=E(&)A8VL@
M=7`@=&AE<V4@=&AO=6=H=',@:6X@=&AE(&-O;G1E>'0@;V8@=&AE($<XXH"M
MXH"=XH"L+N*`K0KB@*Q)=&%L>2!H87,@861O<'1E9"!AXH"M(.*`G.*`K'-E
M8W5R:71Y('!A8VMA9V7B@*WB@)T <at> XH"L:6X <at> 36%YXH"M(.*`K#(P,#CB@*T@
MXH"L=VET:"!F87(M<F5A8VAI;F<*=&EG:'1E;FEN9W,@9F]R($UI9W)A;G1S
M+N*`K2#B@*Q!9G1E<B!T:&4 <at> 154 <at> 86QR96%D>2!E<75I<'!E9"!,:6)Y82!W
M:71H(&9I;F%N8VEA;"!H96QP"F9O<B!R969U9V5E(&1E9F5N<V4LXH"M(.*`
MK&%L<V\@271A;'D@<VEG;F5D(&$@;F5W(&-O;W!E<F%T:6]N(&%G<F5E;65N
M="[B@*T*5&AE($ET86QI86X <at> 87)M<R!C;W)P;W)A=&4 <at> 9W)O=7#B@*T <at> XH"<
MXH"L1FEN;65C8V%N:6-AXH"MXH"=(.*`K&1E;&EV97)S('-P965D8F]A=',@
M86YD('1H90I);G1E<FEO<B!-:6YI<W1R>2!I<R!P;&5A<V5D('1H870@;6EG
M<F%T:6]N('=O=6QD(&YO=R!B92!D:6UI;FES:&5D(&]NXH"M("+B@*QZ97)O
MXH"M(N*`K"X*"D9R871T:6YI('1R879E;&5D(&5A<FQYXH"M(.*`K#(P,#GB
M@*T <at> XH"L=&\@06YG;VQA+.*`K2#B@*Q3:65R<F$@3&5O;F4LXH"M(.*`K%-E
M;F5G86P <at> 86YD($YI9V5R:6$@=&\*;F5G;W1I871E(&]V97+B@*T <at> XH"<XH"L
M<F5A9&UI<W-I;VX <at> 86=R965M96YT<^*`K>*`G2#B@*QF;W(@;6EG<F%N=',L
MXH"M(.*`K'1O(&5Q=6EP('1H92!C;W5N=')I97,*=VET:"!R969U9V5E(&-A
M;7!S+.*`K2#B@*QA;F0@=&\@:6YT<F]D=6-E('1A;7!E<BUP<F]O9B!P87-S
M<&]R=',NXH"M(.*`K$ETXH"9<R!A9V%I;B!A;&P <at> 86)O=70*=&AE('-E8W5R
M:7-A=&EO;B!O9B!R87<@;6%T97)I86P <at> 86YD('!O;&EC92!E;F9O<F-E;65N
M=#KB@*T <at> XH"L26X@<F5T=7)N($9R871T:6YI"F%C:VYO=VQE9&=E<R!A;B!A
M=61I96YC92!W:71H('1H92!'..*`K2#B@*QS=6UM:70 <at> 9F]R('1H92!C;W5N
M=')I97,LXH"M(.*`K'1OXH"M(.*`G.*`K'!R;VUO=&4@=&AE"F1I86QO9W5E
M(&)E='=E96X@;VEL('!R;V1U8VEN9R!A;F3B@*T <at> XH"L+>*`K2#B@*QC;VYS
M=6UI;F<@8V]U;G1R:65SXH"MXH"=XH"L+N*`K0I);B!T:&4 <at> 9&5L96=A=&EO
M;B!T<F%V96QL:6YG($9R871T:6YI+.*`K2#B@*QT:&4 <at> 271A;&EA;B!P;VQI
M8V4 <at> 8VAI968@=VAO(&EM;65D:6%T96QY"FEM<&QE;65N="!N97<@8V]N=')A
M8W1S(&9O<B!P;VQI8V4@=')A:6YI;F<@86YD(&-O;W!E<F%T:6]N('!R;V-E
M9'5R92[B@*T*"N*`K$%S('1H92!C;VYS97%U96YC92!O9B!T:&4 <at> 8V]L;&%P
M<V4@;V8 <at> 9VQO8F%L(&-A<&ET86QI<VT <at> 87)O=6YD('1H92!W;W)L9"SB@*T@
MXH"L;6]R90IU<')I<VEN9W,@87)E(&5X<&5C=&5D+N*`K2#B@*Q7:71H('1H
M92!R96-E;G0@<FEO=',@:6X <at> 1W)E96-E+.*`K2#B@*Q)8V5L86YD+.*`K2#B
M@*Q3=V5D96XLXH"M"N*`K$QI=&AU86YI82SB@*T <at> XH"L3&%T=FEA+.*`K2#B
M@*Q"=6QG87)I82SB@*T <at> XH"L1G)A;F-E+.*`K2#B@*Q'=6%D96QO=7!E(&%N
M9"!,86UP961U<V$LXH"M(.*`K'1H92!%50IB96-A;64@=&AE('9E;G5E(&]F
M(&EN=&5N<V4 <at> 8V]N=')A9&EC=&EO;G,@86YD(&UI;&ET86YT('-T<G5G9VQE
M<R!W:&EC:"[B@*T*26X@=&AE(&YU;65R;W5S(&1I<F5C=&EV97,LXH"M(.*`
MK&)I;&%T97)A;"!A9W)E96UE;G1S(&%N9"!T<F5A=&EE<RSB@*T <at> XH"L;V8@
M=&AE('!A<W0 <at> 9F5W"GEE87)S(&-O;F-E<G1E9"!M96%S=7)E<R!F;W+B@*T@
MXH"<XH"L175R;W!E(&%S(&%N(&%R96$@;V8 <at> 9G)E961O;2SB@*T <at> XH"L<V5C
M=7)I='D <at> 86YD"FIU<W1I8V7B@*WB@)WB@*PLXH"M(.*`K&%R92!L;VYG(&%G
M;R!B<F]U9VAT(&EN=&\@<&]S:71I;VX <at> 86=A:6YS="!A;G1I+6-O;6UU;FES
M="!R97-I<W1A;F-E"F%N9"!R861I8V%L('!R;VIE8W1S(&%N9"!M;W9E;65N
M=',@87)E(&-O=F5R960@=VET:"!I;G9E<W1I9V%T:6]N<R!A;F0@<')O<V5C
M=71I;VYS"F9O<N*`K2`BXH"L=&5R<F]R:7-MXH"M(N*`K"[B@*T <at> XH"<XH"L
M2F]I;G0@:6YV97-T:6=A=&EO;B!T96%M<^*`K>*`G2#B@*QR97-E87)C:.*`
MK2#B@*PMXH"M(.*`K'-U<'!O<G1E9"!B>0I%=7)O<&]LXH"M(.*`K"WB@*T@
MXH"L:6YT97)N871I;VYA;"!N971W;W)K<R[B@*T <at> XH"L36%N=6%L<R!A;F0@
M9&%T86)A<V5S(&]NXH"M(.*`G.*`K%1R;W5B;&5M86ME<G/B@*WB@)T*XH"L
M=VEL;"!B92!B<FEN9R!P<F]T97-T<R!A="!M86IO<B!I;G1E<FYA=&EO;F%L
M(&5V96YT<R!U;F1E<B!C;VYT<F]L+@H*4F5S:7-T86YC92!A9V%I;G-T('1H
M92!I;F-R96%S92!I;B!S=7)V96EL;&%N8V4 <at> 86YD(&-O;G1R;VPLXH"M(.*`
MK&%G86EN<W0@<F5P<F5S<VEO;B!A;F0*86YT:2UR:6]T(&ES('-T:6QL('-T
M=6-K('1O;R!M=6-H(&]F=&5N(&]N(&$@;F%T:6]N86P@;&5V96PNXH"M"N*`
MK%1H97)E9F]R92!W92!C86QL('1O('!U<V@@=&AE(&1E=F5L;W!M96YT(&]F
M(&$@=')A;G-N871I;VYA;"!S=')U9V=L92!A9V%I;G-T('1H9>*`K0KB@)SB
M@*QS96-U<FET>2!A<F-H:71E8W1U<F7B@*WB@)WB@*PLXH"M(.*`K&ENXH"M
M(.*`K#(P,#GB@*T <at> XH"L870@<V5V97)A;"!C<F]S<RUB;W)D97(@;6]B:6QI
M>F%T:6]N<RSB@*T*XH"L=VAE=&AE<B!T:&5Y(&%R92!T:6UB97)E9"!B>2!T
M:&4 <at> 3D%43RSB@*T <at> XH"L1SCB@*T <at> XH"L;W(@154NXH"M"@KB@*Q792!S964@
M=&AE(&%C=&EO;B!D87D <at> 870@=&AE($Y!5$\@<W5M;6ET(&%S('1H92!K:6-K
M(&]F9B!O9B!T:&4 <at> 8V%M<&%I9VX <at> 9F]R(&'B@*T*XH"<XH"L4W5M;65R(&]F
M(%)E<VES=&%N8V7B@*T <at> XH"L,C`P.>*`K>*`G2#B@*QA9V%I;G-T('1H92!G
M;&]B86SB@*T <at> XH"<XH"L<V5C=7)I='D@<F5G:6UEXH"MXH"=XH"L.N*`K0H*
MXH"LPJ%.;R!087-A<L.A;B$@1G)A;F-E('P <at> 1VEP9F5L<V]L:2!\($1I<W-E
M;G0A($9R86YC92!\($YO3&%G97(@0G)E;65N('P <at> 4F5S:7-T86YC92!D97,*
M9&5U>"!R:79E<R`O(%=I9&5R<W1A;F0 <at> 9&5R('IW96D <at> 569E<B!\('1R86YS
M86-T('P@<VEX(&AI;&QS($)E<FQI;B!\(&ME:6X@;65N<V-H(&ES=`II;&QE
M9V%L($AA;F%U"@I#;VQL87!S92!T:&4@<V5C=7)I='D <at> 87)C:&ET96-T=7)E
M<^*`K2$*"B`@("`@*B!H='1P.B\O<W1O8VMH;VQM+FYO8FQO9W,N;W)G"B`@
M("`@*B!H='1P.B\O975R;RUP;VQI8V4N;F]B;&]G<RYO<F<*"BTM(`H*:'1T
M<#HO+RYG:7!F96QS;VQI+F]R9R!\(&AT='`Z+R]E=7)O+7!O;&EC92YN;V)L
M;V=S+F]R9PH*>&UL.B!H='1P.B\O9VEP9F5L<V]L:2YO<F<O<V5R=FEC92]F
M965D7VQI<W0*"G!G<"!\(&=P9SH@:'1T<#HO+V=I<&9E;'-O;&DN;W)G+W-T
M871I8R]G:7!F96QS;VQI0&YA9&ER+F]R9RYA<V,*1$-$,B!!-T9"($8X0S`@
M,S,R-"`Q048R($4R1C`@03%&0B!%.$$S(#A#030 <at> 1#DP0PH*("`@("`J(&1E
M=71S8V <at> Z('=W=RYG:7!F96QS;VQI+F]R9R](;VUE+S8S.30N:'1M;`H@("`@
M("H <at> 9G)A;F-A:7,Z('=W=RYG:7!F96QS;VQI+F]R9R](;VUE+S8S.34N:'1M
M;`H@("`@("H@:71A;&EA;F\@=W=W+F=I<&9E;'-O;&DN;W)G+TAO;64O-C0P
M-"YH=&UL"B`@("`@*B!S=F5N<VMA.B!W=W<N;6]T:W)A9G0N;F5T+VYY:&5T
M97(O,S0X,PH@("`@("H@<W5O;65K<VD@:'1T<#HO+W1A:VMU+FYE="]A<G1I
M8VQE+G!H<"\R,#`Y,#0P-#$P,S,T.3$R-@H]/3T]/3T]/3T]/3T]"BH <at> 06X@
M86YT:6%U=&AO<FET87)I86X <at> 86YT:6-A<&ET86QI<W0@:6YI=&EA=&EV90I?
M7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?7U]?7PI!("T@
M22!.($8 <at> 3R!3("!.($4 <at> 5R!3("!3($4 <at> 4B!6($D <at> 0R!%"D)Y+"!&;W(L(&%N
M9"!!8F]U="!!;F%R8VAI<W1S"E-E;F0@;F5W<R!R97!O<G1S('1O($$M:6YF
M;W,M96X@;6%I;&EN9R!L:7-T"D$M:6YF;W,M96Y`86EN9F]S+F-A"E-U8G-C
M<FEB92]5;G-U8G-C<FEB92!H='1P.B\O86EN9F]S+F-A+V-G:2UB:6XO;6%I
M;&UA;B]L:7-T:6YF;R]A+6EN9F]S+65N"D%R8VAI=F4Z(&AT='`Z+R]A:6YF
(;W,N8V$O96X`
`
end



In GNU Emacs 23.0.94.1 (mipsel-unknown-linux-gnu, GTK+ Version 2.12.12)
 of 2009-05-27 on theobromine2
configured using `configure  'CFLAGS=-O0 -g -Wno-pointer-sign' 'mipsel-unknown-linux-gnu' 'build_alias=mipsel-unknown-linux-gnu' 'host_alias=mipsel-unknown-linux-gnu' 'target_alias=mipsel-unknown-linux-gnu''

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: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: RMAIL

Minor modes in effect:
  gpm-mouse-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
n l y SPC r e s p p j DEL DEL o n d SPC w i t h SPC 
" m a y b e " . RET I SPC d o n ' t SPC k n o w SPC 
w h e t h e r SPC t h e s e SPC ESC DEL C-a C-k I SPC 
c a n n o t SPC j u d g e SPC DEL , SPC b a s e d SPC 
o n SPC t h e SPC a m o u n t SPC o f SPC l i c ESC 
DEL ESC DEL ESC DEL ESC DEL w h a t SPC y o u SPC h 
a v e SPC s a i d , SPC w h e t h e r SPC I SPC w o 
u d l SPC c o n s i d e r ESC b C-b C-b C-t C-e RET 
t h i s SPC g o o d SPC o r SPC b a . DEL d . SPC SPC 
I SPC c a n ESC / ESC SPC ESC / SPC w h ESC / ESC SPC 
ESC / ESC SPC ESC DEL t h e y SPC w o u l d SPC b e 
SPC ESC b ESC b ESC b ESC d i t C-e a SPC f r e e SPC 
l i c e n s e . RET C-c C-c d x C-l C-x h ESC x w r 
SPC r e RET f o o . m s g RET C-x C-f ESC p RET C-l 
ESC x C-g C-x k RET ESC x r e p o r t SPC e m a c TAB 
RET

Recent messages:
Auto-saving...done
Mark set [2 times]
Auto-saving...done
Sending...
Wrote /home/rms/outgoing/out-56
Sending...done
No following nondeleted message
Expunging deleted messages...done
Mark set [2 times]
Wrote /home/rms/foo.msg
Quit

Message #12 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa  <handa <at> m17n.org>
Cc: 3452 <at> debbugs.gnu.org
Subject: Re: 23.0.94; display
Date: Fri, 05 Jun 2009 22:48:59 -0400

[Message part 1 (text/plain, inline)]

Richard Stallman <rms <at> gnu.org> wrote: 

> Visiting the file foo.msg after emacs -Q in a 37-line Linux terminal
> garbles the screen, including the mode line and menu bar.

The problem stems from the character 8237 (#o20055, #x202d),
LEFT-TO-RIGHT OVERRIDE.  For some reason, the composition for this
character screws up line wrapping.

For a simpler test case, see the attached file.  The first line uses
character 8237 and is incorrectly wrapped; the second line uses spaces
and is correctly wrapped.

Handa-san, do you have an idea what the problem might be?  If not, I'll
try to debug.

[foo.txt (text/plain, inline)]

‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭‭AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA

                                                        BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB BBB

Message #17 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa  <handa <at> m17n.org>
Cc: 3452 <at> debbugs.gnu.org
Subject: Re: 23.0.94; display
Date: Sat, 06 Jun 2009 23:47:26 -0400

> The problem stems from the character 8237 (#o20055, #x202d),
> LEFT-TO-RIGHT OVERRIDE.  For some reason, the composition for this
> character screws up line wrapping.

Hi Handa-san, I investigated some more.  Let me know what you think.

The entry for 8237 (#x202d) in char-width-table is 0: that is to say,
char-width-table reports that the composition has zero width.  This is
because of the following code in characters.el:

  (let ((l '((#x0300 . #x036F)
            ...
            (#x202A . #x202E)
            (#xE0001 . #xE01EF))))
    (dolist (elt l)
      (set-char-table-range char-width-table elt 0)))

The function fill_gstring_body in composite.c uses char-width-table.
However, composition_gstring_width for this character, called in
term.c:1830, returns 1.  This inconsistency leads to the bug.

Sure enough, if I do

  (aset char-width-table #x202d 1)

then the screen corruption goes away.

Maybe we should reconsider setting these characters to have zero-width
for char-width-table in characters.el, since fill-gstring-body seems to
handle zero-width compositions poorly.  WDYT?

Message #22 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>, 3452 <at> debbugs.gnu.org
Cc: handa <at> m17n.org
Subject: Re: bug#3452: 23.0.94; display
Date: Sun, 07 Jun 2009 05:16:05 -0400

> From: Chong Yidong <cyd <at> stupidchicken.com>
> Date: Sat, 06 Jun 2009 23:47:26 -0400
> Cc: 3452 <at> emacsbugs.donarmstrong.com
> Reply-To: Chong Yidong <cyd <at> stupidchicken.com>, 3452 <at> emacsbugs.donarmstrong.com
> 
> Sure enough, if I do
> 
>   (aset char-width-table #x202d 1)
> 
> then the screen corruption goes away.
> 
> Maybe we should reconsider setting these characters to have zero-width
> for char-width-table in characters.el, since fill-gstring-body seems to
> handle zero-width compositions poorly.  WDYT?

I think it would be a bad idea to set these characters to anything but
zero width.  These characters are not supposed to be displayed at all,
they have no meaningful glyphs to show them.  They are just directives
to the bidirectional display engines about how to convert logical
order of characters to visual order.

Not to mention the fact that the Unicode standard explicitly calls
them zero-width.

We should find a different way to handle this problem.

Btw, I don't understand how these characters are related to
compositions.  They should not be composed with anything, they always
stand for themselves.

Message #27 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 3452 <at> debbugs.gnu.org, handa <at> m17n.org
Subject: Re: bug#3452: 23.0.94; display
Date: Sun, 07 Jun 2009 09:56:05 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

> Btw, I don't understand how these characters are related to
> compositions.  They should not be composed with anything, they always
> stand for themselves.

I didn't know that.  This means there is a bug in either
find_composition (called from composition_compute_stop_pos) or
next_element_from_composition (called from next_element_from_buffer),
because the following code in next_element_from_buffer (xdisp.c:6519) is
triggered for this character:

  if (CHAR_COMPOSED_P (it, IT_CHARPOS (*it), IT_BYTEPOS (*it))
      && next_element_from_composition (it))
    {
       return 1;
    }

Message #32 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 3452 <at> debbugs.gnu.org, handa <at> m17n.org
Subject: Re: bug#3452: 23.0.94; display
Date: Sun, 07 Jun 2009 10:30:20 -0400

> From: Chong Yidong <cyd <at> stupidchicken.com>
> Cc: 3452 <at> emacsbugs.donarmstrong.com,  handa <at> m17n.org
> Date: Sun, 07 Jun 2009 09:56:05 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Btw, I don't understand how these characters are related to
> > compositions.  They should not be composed with anything, they always
> > stand for themselves.
> 
> I didn't know that.  This means there is a bug in either
> find_composition (called from composition_compute_stop_pos) or
> next_element_from_composition (called from next_element_from_buffer),
> because the following code in next_element_from_buffer (xdisp.c:6519) is
> triggered for this character:
> 
>   if (CHAR_COMPOSED_P (it, IT_CHARPOS (*it), IT_BYTEPOS (*it))
>       && next_element_from_composition (it))
>     {
>        return 1;
>     }

I hope Handa-san could shed some light on this issue.

Message #37 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 3452 <at> debbugs.gnu.org, handa <at> m17n.org
Subject: Re: bug#3452: 23.0.94; display
Date: Sun, 07 Jun 2009 16:41:33 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

> Btw, I don't understand how these characters are related to
> compositions.  They should not be composed with anything, they always
> stand for themselves.

Actually, according to composition-function-table:

M-: (aref composition-function-table #x202d)

 => ([\c.\c^+ 1 compose-gstring-for-graphic]
     [nil 0 compose-gstring-for-graphic])

All zero-width characters are explicitly given non-nil entries in
composition-function-table, in composite.el:

(let ((elt '(["\\c.\\c^+" 1 compose-gstring-for-graphic]
             [nil 0 compose-gstring-for-graphic])))
  (map-char-table
   #'(lambda (key val)
       (if (= val 0)
           (set-char-table-range composition-function-table key elt)))
   char-width-table))

Message #42 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 3452 <at> debbugs.gnu.org, handa <at> m17n.org
Subject: Re: bug#3452: 23.0.94; display
Date: Sun, 07 Jun 2009 18:53:50 -0400

> From: Chong Yidong <cyd <at> stupidchicken.com>
> Cc: 3452 <at> emacsbugs.donarmstrong.com,  handa <at> m17n.org
> Date: Sun, 07 Jun 2009 16:41:33 -0400
> 
> Actually, according to composition-function-table:
> 
> M-: (aref composition-function-table #x202d)
> 
>  => ([\c.\c^+ 1 compose-gstring-for-graphic]
>      [nil 0 compose-gstring-for-graphic])
> 
> All zero-width characters are explicitly given non-nil entries in
> composition-function-table, in composite.el:
> 
> (let ((elt '(["\\c.\\c^+" 1 compose-gstring-for-graphic]
>              [nil 0 compose-gstring-for-graphic])))
>   (map-char-table
>    #'(lambda (key val)
>        (if (= val 0)
>            (set-char-table-range composition-function-table key elt)))
>    char-width-table))

I don't see why this should be applicable to the characters in
question.  Perhaps the code you found assumes that any zero-width
character is necessarily a non-base character to be used in
compositions.  If so, this is a mistake, I think.

Message #47 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 3452 <at> debbugs.gnu.org
Subject: Re: 23.0.94; display
Date: Mon, 08 Jun 2009 10:51:14 +0900

In article <877hzoogc1.fsf <at> cyd.mit.edu>, Chong Yidong <cyd <at> stupidchicken.com> writes:

> > The problem stems from the character 8237 (#o20055, #x202d),
> > LEFT-TO-RIGHT OVERRIDE.  For some reason, the composition for this
> > character screws up line wrapping.

> Hi Handa-san, I investigated some more.  Let me know what you think.

> The entry for 8237 (#x202d) in char-width-table is 0: that is to say,
> char-width-table reports that the composition has zero width.  This is
> because of the following code in characters.el:

>   (let ((l '((#x0300 . #x036F)
>             ...
>             (#x202A . #x202E)
>             (#xE0001 . #xE01EF))))
>     (dolist (elt l)
>       (set-char-table-range char-width-table elt 0)))

> The function fill_gstring_body in composite.c uses char-width-table.
> However, composition_gstring_width for this character, called in
> term.c:1830, returns 1.  This inconsistency leads to the bug.

There's no inconsistency.

On terminal, if a zero-width character doesn't follow a base
character, Emacs composes that character by prepending SPACE
hoping that the terminal treats that zero-width character as
zero-width too.  This is to make that character still
edittable (e.g. we can put cursor on it) in Emacs.

So, even if char-width-table says it's zero width, all Emacs
display routines including indent.c treat that character's
width as 1.

But, gnome-terminal doesn't treat that character as
zero-width.  Please make the file "temp" by this code:

(with-temp-file "~/temp" (insert #x202d ?a ?\n))

and do "% cat ~/temp" on gnome-terminal.

> Maybe we should reconsider setting these characters to have zero-width
> for char-width-table in characters.el, since fill-gstring-body seems to
> handle zero-width compositions poorly.  WDYT?

fill_gstring_body (in composite.c) just initializes gstring.
The actual composition function
(compose-gstring-for-terminal on terminal) does the above
composition.

In article <E1MDEU1-0004sV-3H <at> fencepost.gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:

> I think it would be a bad idea to set these characters to anything but
> zero width.

I agree with that.

> These characters are not supposed to be displayed at all,
> they have no meaningful glyphs to show them.  They are just directives
> to the bidirectional display engines about how to convert logical
> order of characters to visual order.

But as Emacs 23 doesn't support bidi, at least we should
make it edittable, don't we?

> Btw, I don't understand how these characters are related to
> compositions.  They should not be composed with anything, they always
> stand for themselves.

Currently they are not composed with any other surrounding
characters (but only with an artificially prepended SPACE),
so we can say that they stand for themselves.

To conclude, I think there's not that much we can do for
this situation.  I think the current behaviour of
gnome-terminal (displaying standalone U+202D as a space of
width 1) is a bug.

---
Kenichi Handa
handa <at> m17n.org

Message #52 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>, 3452 <at> debbugs.gnu.org
Cc: cyd <at> stupidchicken.com
Subject: Re: bug#3452: 23.0.94; display
Date: Mon, 08 Jun 2009 00:48:53 -0400

> From: Kenichi Handa <handa <at> m17n.org>
> Date: Mon, 08 Jun 2009 10:51:14 +0900
> Cc: 3452 <at> emacsbugs.donarmstrong.com
> Reply-To: Kenichi Handa <handa <at> m17n.org>, 3452 <at> emacsbugs.donarmstrong.com
> 
> On terminal, if a zero-width character doesn't follow a base
> character, Emacs composes that character by prepending SPACE
> hoping that the terminal treats that zero-width character as
> zero-width too.

So these characters should be currently displayed as SPACE?

Is it a good idea to rely on the terminal in this situation?  Do we
know for a fact that many (most?) terminals indeed behave like that
with zero-width characters?

> > These characters are not supposed to be displayed at all,
> > they have no meaningful glyphs to show them.  They are just directives
> > to the bidirectional display engines about how to convert logical
> > order of characters to visual order.
> 
> But as Emacs 23 doesn't support bidi, at least we should
> make it edittable, don't we?

Yes, definitely.  (Btw, I think make them editable even when Emacs
does support bidirectional editing.)

> > Btw, I don't understand how these characters are related to
> > compositions.  They should not be composed with anything, they always
> > stand for themselves.
> 
> Currently they are not composed with any other surrounding
> characters (but only with an artificially prepended SPACE),
> so we can say that they stand for themselves.

That's good, I think.

> To conclude, I think there's not that much we can do for
> this situation.  I think the current behaviour of
> gnome-terminal (displaying standalone U+202D as a space of
> width 1) is a bug.

If other terminals behave correctly, I would agree.  But if not,
perhaps we need to work around this, if possible.  For example, we
could have an entry in display tables for these characters.

Message #57 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 3452 <at> debbugs.gnu.org, cyd <at> stupidchicken.com
Subject: Re: bug#3452: 23.0.94; display
Date: Mon, 08 Jun 2009 17:10:27 +0900

In article <E1MDWmz-0001XD-Tm <at> fencepost.gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:

> > On terminal, if a zero-width character doesn't follow a base
> > character, Emacs composes that character by prepending SPACE
> > hoping that the terminal treats that zero-width character as
> > zero-width too.

> So these characters should be currently displayed as SPACE?

Yes, that's my intention.

> Is it a good idea to rely on the terminal in this situation?  Do we
> know for a fact that many (most?) terminals indeed behave like that
> with zero-width characters?

I'm not sure but I thought that it's reasonable to assume
that a character defined as zero-width by Unicode does not
occupy a screen column by itself.

Not for U+202D, but such combining characters as U+0300 are
treated correctly by xterm (not by gnome-terminal).

> > To conclude, I think there's not that much we can do for
> > this situation.  I think the current behaviour of
> > gnome-terminal (displaying standalone U+202D as a space of
> > width 1) is a bug.

> If other terminals behave correctly, I would agree.  But if not,
> perhaps we need to work around this, if possible.  For example, we
> could have an entry in display tables for these characters.

It seems xterm, gnome-terminal, GNU/Linux console, and
mlterm treat U+202D as spacing character, but, Konsole
(KDE's terminal) and kterm treats it as non-spacing
character.

---
Kenichi Handa
handa <at> m17n.org

Message #62 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 3452 <at> debbugs.gnu.org, cyd <at> stupidchicken.com
Subject: Re: bug#3452: 23.0.94; display
Date: Mon, 08 Jun 2009 04:44:50 -0400

> From: Kenichi Handa <handa <at> m17n.org>
> CC: 3452 <at> emacsbugs.donarmstrong.com, cyd <at> stupidchicken.com
> Date: Mon, 08 Jun 2009 17:10:27 +0900
> 
> Not for U+202D, but such combining characters as U+0300 are
> treated correctly by xterm (not by gnome-terminal).
> 
> > > To conclude, I think there's not that much we can do for
> > > this situation.  I think the current behaviour of
> > > gnome-terminal (displaying standalone U+202D as a space of
> > > width 1) is a bug.
> 
> > If other terminals behave correctly, I would agree.  But if not,
> > perhaps we need to work around this, if possible.  For example, we
> > could have an entry in display tables for these characters.
> 
> It seems xterm, gnome-terminal, GNU/Linux console, and
> mlterm treat U+202D as spacing character, but, Konsole
> (KDE's terminal) and kterm treats it as non-spacing
> character.

Wasn't gnome-terminal the one that started this bug report?  And you
even tell above that gnome-terminal does NOT treat U+202D correctly.
So which terminals do?

If xterm, the Linux console and mlterm do work, then maybe your
suggestion to do nothing is good enough.

Btw, what do you think about my idea to add a display table entry for
these characters?

Message #67 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 3452 <at> debbugs.gnu.org, cyd <at> stupidchicken.com
Subject: Re: bug#3452: 23.0.94; display
Date: Mon, 08 Jun 2009 20:57:06 +0900

In article <E1MDaTK-0001yD-LX <at> fencepost.gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:

> > From: Kenichi Handa <handa <at> m17n.org>
> > CC: 3452 <at> emacsbugs.donarmstrong.com, cyd <at> stupidchicken.com
> > Date: Mon, 08 Jun 2009 17:10:27 +0900
> > 
> > Not for U+202D, but such combining characters as U+0300 are
> > treated correctly by xterm (not by gnome-terminal).
> > 
> > > > To conclude, I think there's not that much we can do for
> > > > this situation.  I think the current behaviour of
> > > > gnome-terminal (displaying standalone U+202D as a space of
> > > > width 1) is a bug.
> > 
> > > If other terminals behave correctly, I would agree.  But if not,
> > > perhaps we need to work around this, if possible.  For example, we
> > > could have an entry in display tables for these characters.
> > 
> > It seems xterm, gnome-terminal, GNU/Linux console, and
> > mlterm treat U+202D as spacing character, but, Konsole
> > (KDE's terminal) and kterm treats it as non-spacing
> > character.

> Wasn't gnome-terminal the one that started this bug report?

I don't know exactly.  RMS's bug report just says "a 37-line
Linux terminal".

> And you even tell above that gnome-terminal does NOT treat
> U+202D correctly.  So which terminals do?

> If xterm, the Linux console and mlterm do work, then maybe your
> suggestion to do nothing is good enough.

??? I wrote "Konsole and kterm" treats U+202D as non-spacing
character.  I think that is the correct way, and the others
(gnome-terminal, xterm, and Linux console) are wrong.

> Btw, what do you think about my idea to add a display table entry for
> these characters?

A display table is used both for terminal and window system,
but, on a window system, some font may have special glyphs
for those characters.  If we setup a display table for
U+202D, Emacs can't display U+202D by such a glyph on window
system.

So, if we implement some work-around for such terminal as
gnome-terminal, I think it is better to modify
compose-gstring-for-terminal so that it replaces U+202D
(actually all zero-width characters of Unicode category Cf)
with a single SPACE instead of prepending a SPACE.  Please
try the attached patch.

---
Kenichi Handa
handa <at> m17n.org

--- composite.el.~1.46.~	2009-04-20 10:11:33.000000000 +0900
+++ composite.el	2009-06-08 20:45:50.000000000 +0900
@@ -681,7 +681,14 @@
 	      (lglyph-set-from-to glyph i i)
 	      (setq i (1+ i))))
 	(if (= (lglyph-width glyph) 0)
-	    (progn
+	    (if (eq (get-char-code-property (lglyph-char glyph)
+					    'general-category)
+		    'Cf)
+		(progn
+		  ;; Compose by replacing with a space.
+		  (lglyph-set-char glyph 32)
+		  (lglyph-set-width glyph 1)
+		  (setq i (1+ i)))
 	      ;; Compose by prepending a space.
 	      (setq gstring (lgstring-insert-glyph gstring i
 						   (lglyph-copy glyph))

Message #72 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa <handa <at> m17n.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 3452 <at> debbugs.gnu.org
Subject: Re: bug#3452: 23.0.94; display
Date: Mon, 08 Jun 2009 10:47:38 -0400

Kenichi Handa <handa <at> m17n.org> writes:

>> > It seems xterm, gnome-terminal, GNU/Linux console, and
>> > mlterm treat U+202D as spacing character, but, Konsole
>> > (KDE's terminal) and kterm treats it as non-spacing
>> > character.
>
>> Wasn't gnome-terminal the one that started this bug report?
>
> I don't know exactly.  RMS's bug report just says "a 37-line
> Linux terminal".

He means the console on GNU/Linux.  I haven't tested there.

The problem I see is on xterm, where the current behavior is very
strange.  For example, with your earlier example:

(with-temp-file "~/atemp" (insert #x202d ?a ?\n))

Visit the file with emacs -nw -Q on an xterm and press C-f a few times.
You'll see that the "a" is displayed one glyph to the right of where it
should be.  Apprently, the console draws #x202d as two spaces, and this
leads to inconsistent display.

The same problem occurs on gnome-terminal.

Message #77 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa <handa <at> m17n.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 3452 <at> debbugs.gnu.org
Subject: Re: bug#3452: 23.0.94; display
Date: Tue, 09 Jun 2009 14:00:43 -0400

Kenichi Handa <handa <at> m17n.org> writes:

> So, if we implement some work-around for such terminal as
> gnome-terminal, I think it is better to modify
> compose-gstring-for-terminal so that it replaces U+202D
> (actually all zero-width characters of Unicode category Cf)
> with a single SPACE instead of prepending a SPACE.  Please
> try the attached patch.

The patch works very well.  Could you check it in?  Thanks.

Message #82 received at 3452 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: eliz <at> gnu.org, 3452 <at> debbugs.gnu.org
Subject: Re: bug#3452: 23.0.94; display
Date: Wed, 10 Jun 2009 09:35:59 +0900

In article <87fxe9p9ro.fsf <at> cyd.mit.edu>, Chong Yidong <cyd <at> stupidchicken.com> writes:

> Kenichi Handa <handa <at> m17n.org> writes:
> > So, if we implement some work-around for such terminal as
> > gnome-terminal, I think it is better to modify
> > compose-gstring-for-terminal so that it replaces U+202D
> > (actually all zero-width characters of Unicode category Cf)
> > with a single SPACE instead of prepending a SPACE.  Please
> > try the attached patch.

> The patch works very well.  Could you check it in?  Thanks.

Ok, done.

---
Kenichi Handa
handa <at> m17n.org

Message #87 received at 3452-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa <handa <at> m17n.org>
Cc: eliz <at> gnu.org, 3452-done <at> debbugs.gnu.org
Subject: Re: bug#3452: 23.0.94; display
Date: Wed, 10 Jun 2009 10:20:01 -0400

>> The patch works very well.  Could you check it in?  Thanks.
>
> Ok, done.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.