From unknown Tue Jun 24 19:08:24 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#3452 <3452@debbugs.gnu.org> To: bug#3452 <3452@debbugs.gnu.org> Subject: Status: 23.0.94; display Reply-To: bug#3452 <3452@debbugs.gnu.org> Date: Wed, 25 Jun 2025 02:08:24 +0000 retitle 3452 23.0.94; display reassign 3452 emacs submitter 3452 rms@gnu.org severity 3452 serious thanks From rms@gnu.org Tue Jun 2 19:53:26 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 3 Jun 2009 02:53:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.5 required=4.0 tests=AWL,FOURLA,FVGT_m_MULTI_ODD, MONEY,STOCKLIKE autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n532rFxK021288 for ; Tue, 2 Jun 2009 19:53:16 -0700 Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MBgbK-0007fG-KQ; Tue, 02 Jun 2009 22:53:14 -0400 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman To: emacs-pretest-bug@gnu.org Subject: 23.0.94; display Reply-to: rms@gnu.org Message-Id: 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-T871U5]A M'0O<&QA:6X[(&-H87)S970](G5T9BTX(@H*"D%G86EN"!A;F0@=&AE(.*`G%-T;V-K:&]L;2!0*`K2`BXH"L175R;W!E86X@1V5N9&%R;65R:64@1F]R8V7B@*T@*.*` MK$5'1N*`K2D@XH"L=V%S"F9O=6YD960@86YD(&AA*`K2#B@)SB@*QP=6)L:6,*;W)D97+B@*WB@)WB@*PLXH"M(.*`K&-O M;6)A="!I;G-U'!E8W1E9"[B@*T*XH"L5&AE(&ENF4*=&AE;7-E;'9EF%T:6]N+N*`K2#B@*Q4;W!I8W,@65A2SB@*T@XH"L=V%S('!R:6UA2!AXH"M(.*`G.*`K&UA;F%G M96UE;G0@;V8*;6EG*`K>*`G2#B@*QI;N*`K2#B@*PR,#`T+.*`K2#B M@*QI="!H87,@8F5E;B!A9W)E960@=7!O;B!T:&4@8W)E871I;VX@;V8@86[B M@*T*XH"2!A;F0@ M:G5S=&EC9>*`K>*`G>*`K"[B@*T@XH"L06=A:6X@:70@=V%S(&1E8VED960@ M;VX*:6YT96YS:69I8V%T:6]N2!I;B!T:&5I*`K2#B@)SB@*QP*`K2#B@*PR,#`YXH"M(.*` MK&YE=R!B:6]M971R:6,@:61E;G1I9FEE*`K2#B@)SB M@*Q&=71U>*`K>*`G2#B@*QO9B!%=7)O<&5A;B!I;G1E M6QU;2!A;F0@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'1E>*`K>*`G2#B@*QA;F0@96YS=7)I;F<@;V;B M@*T@XH"*`G>*`K"X*"E1H92!M96%S=7)E2!T:&4*;65M8F5R('-T871E>*`K2#B@)SB@*Q%=7)O<&5A;B!'96YD87)M97)I92!& M;W)C9>*`K>*`G>*`K"SB@*T@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-E2!A;F0@:G5S=&EC9>*`K>*`G2#B@*QF*`K0KB M@)SB@*QS=')O;F<@9&5F96YS9>*`K>*`G2#B@*QT;R!T:&4@;W5T2SB@*T@XH"L=')A;G-P;W)T871I M;VXLXH"M(.*`K&-O;6UU;FEC871I;V[B@*TIXH"L+N*`K0KB@*Q4:&4@"UG96YE2!T:&4@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@XH"F%T:6]N(&]F('-O8VEA;"!C;VYF;&EC=',@:7,*:6YC M>*`K2#B@*PR,#`X+N*`K2#B M@*Q!2[B@*T@XH"L0G5T M($55(&%N9"!.051/(&YE960@=&\@:6YT96=R871E+.*`K2#B@*QR871H97(@ M=&\@:6YT97)F97)E('=I=&@@96%C:"!O=&AE'0@;V8@=&AE($2!H87,@861O<'1E9"!AXH"M(.*`G.*`K'-E M8W5R:71Y('!A8VMA9V7B@*WB@)T@XH"L:6X@36%YXH"M(.*`K#(P,#CB@*T@ MXH"L=VET:"!F87(M2!E<75I<'!E9"!,:6)Y82!W M:71H(&9I;F%N8VEA;"!H96QP"F9O2!I*`G2#B@*QF;W(@;6EG*`K2#B@*QC;VYS M=6UI;F<@8V]U;G1R:65SXH"MXH"=XH"L+N*`K0I);B!T:&4@9&5L96=A=&EO M;B!T*`G2#B@*QR97-E87)C:.*` MK2#B@*PMXH"M(.*`K'-U<'!O0I%=7)O<&]LXH"M(.*`K"WB@*T@ MXH"L:6YT97)N871I;VYA;"!N971W;W)K*`K0KB@)SB M@*QS96-U2!AF%T:6]N2!T M:&4@3D%43RSB@*T@XH"L1SCB@*T@XH"L;W(@154NXH"M"@KB@*Q792!S964@ M=&AE(&%C=&EO;B!D87D@870@=&AE($Y!5$\@*`K>*`G2#B@*QA9V%I;G-T('1H92!G M;&]B86SB@*T@XH""!R:79E; Fri, 5 Jun 2009 15:40:10 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 2EFB257E21E; Fri, 5 Jun 2009 18:40:12 -0400 (EDT) From: Chong Yidong To: control@debbugs.gnu.org Subject: severity 3452 serious Date: Fri, 05 Jun 2009 18:40:12 -0400 Message-ID: <87k53qe243.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii severity 3452 serious thanks From cyd@stupidchicken.com Fri Jun 5 19:49:00 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 6 Jun 2009 02:49:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n562muTM014794 for <3452@emacsbugs.donarmstrong.com>; Fri, 5 Jun 2009 19:48:58 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 7B30A57E21E; Fri, 5 Jun 2009 22:48:59 -0400 (EDT) From: Chong Yidong To: Kenichi Handa Cc: 3452@debbugs.gnu.org Subject: Re: 23.0.94; display Date: Fri, 05 Jun 2009 22:48:59 -0400 Message-ID: <87hbyurs9w.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Richard Stallman 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. --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline; filename=foo.txt Content-Transfer-Encoding: base64 4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt 4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt 4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCt4oCtQUFB IEFBQSBBQUEgQUFBIEFBQSBBQUEgQUFBIEFBQSBBQUEgQUFBIEFBQSBBQUEgQUFBDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQkJCIEJC QiBCQkIgQkJCIEJCQiBCQkIgQkJCIEJCQiBCQkIgQkJCIEJCQiBCQkIgQkJCDQo= --=-=-=-- From cyd@stupidchicken.com Sat Jun 6 20:47:27 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 7 Jun 2009 03:47:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n573lNwU013889 for <3452@emacsbugs.donarmstrong.com>; Sat, 6 Jun 2009 20:47:24 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 7C2A257E233; Sat, 6 Jun 2009 23:47:26 -0400 (EDT) From: Chong Yidong To: Kenichi Handa Cc: 3452@debbugs.gnu.org Subject: Re: 23.0.94; display Date: Sat, 06 Jun 2009 23:47:26 -0400 Message-ID: <877hzoogc1.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > 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? From eliz@gnu.org Sun Jun 7 02:16:12 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 7 Jun 2009 09:16:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n579G8gV007040 for <3452@emacsbugs.donarmstrong.com>; Sun, 7 Jun 2009 02:16:09 -0700 Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MDEU1-0004sV-3H; Sun, 07 Jun 2009 05:16:05 -0400 From: Eli Zaretskii To: Chong Yidong , 3452@debbugs.gnu.org CC: handa@m17n.org In-reply-to: <877hzoogc1.fsf@cyd.mit.edu> (message from Chong Yidong on Sat, 06 Jun 2009 23:47:26 -0400) Subject: Re: bug#3452: 23.0.94; display Reply-to: Eli Zaretskii References: <877hzoogc1.fsf@cyd.mit.edu> Message-Id: Date: Sun, 07 Jun 2009 05:16:05 -0400 > From: Chong Yidong > Date: Sat, 06 Jun 2009 23:47:26 -0400 > Cc: 3452@emacsbugs.donarmstrong.com > Reply-To: Chong Yidong , 3452@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. From cyd@stupidchicken.com Sun Jun 7 06:56:06 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 7 Jun 2009 13:56:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n57Du1t6021813 for <3452@emacsbugs.donarmstrong.com>; Sun, 7 Jun 2009 06:56:03 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 0910357E246; Sun, 7 Jun 2009 09:56:05 -0400 (EDT) From: Chong Yidong To: Eli Zaretskii Cc: 3452@debbugs.gnu.org, handa@m17n.org Subject: Re: bug#3452: 23.0.94; display References: <877hzoogc1.fsf@cyd.mit.edu> Date: Sun, 07 Jun 2009 09:56:05 -0400 In-Reply-To: (Eli Zaretskii's message of "Sun, 07 Jun 2009 05:16:05 -0400") Message-ID: <87r5xwgnbe.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Eli Zaretskii 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; } From eliz@gnu.org Sun Jun 7 07:30:26 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 7 Jun 2009 14:30:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n57EUM7L028142 for <3452@emacsbugs.donarmstrong.com>; Sun, 7 Jun 2009 07:30:23 -0700 Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MDJO8-0004yP-Et; Sun, 07 Jun 2009 10:30:20 -0400 From: Eli Zaretskii To: Chong Yidong CC: 3452@debbugs.gnu.org, handa@m17n.org In-reply-to: <87r5xwgnbe.fsf@cyd.mit.edu> (message from Chong Yidong on Sun, 07 Jun 2009 09:56:05 -0400) Subject: Re: bug#3452: 23.0.94; display Reply-to: Eli Zaretskii References: <877hzoogc1.fsf@cyd.mit.edu> <87r5xwgnbe.fsf@cyd.mit.edu> Message-Id: Date: Sun, 07 Jun 2009 10:30:20 -0400 > From: Chong Yidong > Cc: 3452@emacsbugs.donarmstrong.com, handa@m17n.org > Date: Sun, 07 Jun 2009 09:56:05 -0400 > > Eli Zaretskii 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. From cyd@stupidchicken.com Sun Jun 7 13:41:33 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 7 Jun 2009 20:41:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n57KfT7B025647 for <3452@emacsbugs.donarmstrong.com>; Sun, 7 Jun 2009 13:41:31 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 62C6957E246; Sun, 7 Jun 2009 16:41:33 -0400 (EDT) From: Chong Yidong To: Eli Zaretskii Cc: 3452@debbugs.gnu.org, handa@m17n.org Subject: Re: bug#3452: 23.0.94; display References: <877hzoogc1.fsf@cyd.mit.edu> Date: Sun, 07 Jun 2009 16:41:33 -0400 In-Reply-To: (Eli Zaretskii's message of "Sun, 07 Jun 2009 05:16:05 -0400") Message-ID: <87iqj76aki.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Eli Zaretskii 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)) From eliz@gnu.org Sun Jun 7 15:53:56 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 7 Jun 2009 22:53:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,HAS_BUG_NUMBER, MDO_CABLE_TV3 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n57MrpOp015078 for <3452@emacsbugs.donarmstrong.com>; Sun, 7 Jun 2009 15:53:53 -0700 Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MDRFO-0007lU-9D; Sun, 07 Jun 2009 18:53:50 -0400 From: Eli Zaretskii To: Chong Yidong CC: 3452@debbugs.gnu.org, handa@m17n.org In-reply-to: <87iqj76aki.fsf@cyd.mit.edu> (message from Chong Yidong on Sun, 07 Jun 2009 16:41:33 -0400) Subject: Re: bug#3452: 23.0.94; display Reply-to: Eli Zaretskii References: <877hzoogc1.fsf@cyd.mit.edu> <87iqj76aki.fsf@cyd.mit.edu> Message-Id: Date: Sun, 07 Jun 2009 18:53:50 -0400 > From: Chong Yidong > Cc: 3452@emacsbugs.donarmstrong.com, handa@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. From handa@m17n.org Sun Jun 7 18:51:23 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 8 Jun 2009 01:51:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,FOURLA,SPF_HELO_PASS autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n581pIti012543 for <3452@emacsbugs.donarmstrong.com>; Sun, 7 Jun 2009 18:51:19 -0700 Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id n581pF6u018487; Mon, 8 Jun 2009 10:51:15 +0900 (JST) env-from (handa@m17n.org) Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id n581pF2G011119; Mon, 8 Jun 2009 10:51:15 +0900 (JST) env-from (handa@m17n.org) Received: by smtp4.aist.go.jp with ESMTP id n581pEVq016566; Mon, 8 Jun 2009 10:51:14 +0900 (JST) env-from (handa@m17n.org) Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1MDU14-0000xn-M7; Mon, 08 Jun 2009 10:51:14 +0900 From: Kenichi Handa To: Chong Yidong CC: 3452@debbugs.gnu.org In-reply-to: <877hzoogc1.fsf@cyd.mit.edu> (message from Chong Yidong on Sat, 06 Jun 2009 23:47:26 -0400) Subject: Re: 23.0.94; display References: <877hzoogc1.fsf@cyd.mit.edu> Message-Id: Date: Mon, 08 Jun 2009 10:51:14 +0900 In article <877hzoogc1.fsf@cyd.mit.edu>, Chong Yidong 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 , Eli Zaretskii 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@m17n.org From eliz@gnu.org Sun Jun 7 21:49:03 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 8 Jun 2009 04:49:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n584mth8007300 for <3452@emacsbugs.donarmstrong.com>; Sun, 7 Jun 2009 21:48:57 -0700 Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MDWmz-0001XD-Tm; Mon, 08 Jun 2009 00:48:53 -0400 From: Eli Zaretskii To: Kenichi Handa , 3452@debbugs.gnu.org CC: cyd@stupidchicken.com In-reply-to: (message from Kenichi Handa on Mon, 08 Jun 2009 10:51:14 +0900) Subject: Re: bug#3452: 23.0.94; display Reply-to: Eli Zaretskii References: <877hzoogc1.fsf@cyd.mit.edu> Message-Id: Date: Mon, 08 Jun 2009 00:48:53 -0400 > From: Kenichi Handa > Date: Mon, 08 Jun 2009 10:51:14 +0900 > Cc: 3452@emacsbugs.donarmstrong.com > Reply-To: Kenichi Handa , 3452@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. From handa@m17n.org Mon Jun 8 01:10:35 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 8 Jun 2009 08:10:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, SPF_HELO_PASS autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n588ATVk008018 for <3452@emacsbugs.donarmstrong.com>; Mon, 8 Jun 2009 01:10:31 -0700 Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id n588ASgn005070; Mon, 8 Jun 2009 17:10:28 +0900 (JST) env-from (handa@m17n.org) Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id n588ASu8018615; Mon, 8 Jun 2009 17:10:28 +0900 (JST) env-from (handa@m17n.org) Received: by smtp2.aist.go.jp with ESMTP id n588ARO5017662; Mon, 8 Jun 2009 17:10:27 +0900 (JST) env-from (handa@m17n.org) Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1MDZw3-0002b5-Gq; Mon, 08 Jun 2009 17:10:27 +0900 From: Kenichi Handa To: Eli Zaretskii CC: 3452@debbugs.gnu.org, cyd@stupidchicken.com In-reply-to: (message from Eli Zaretskii on Mon, 08 Jun 2009 00:48:53 -0400) Subject: Re: bug#3452: 23.0.94; display References: <877hzoogc1.fsf@cyd.mit.edu> Message-Id: Date: Mon, 08 Jun 2009 17:10:27 +0900 In article , Eli Zaretskii 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@m17n.org From eliz@gnu.org Mon Jun 8 01:44:56 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 8 Jun 2009 08:44:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n588ipPV012920 for <3452@emacsbugs.donarmstrong.com>; Mon, 8 Jun 2009 01:44:53 -0700 Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MDaTK-0001yD-LX; Mon, 08 Jun 2009 04:44:50 -0400 From: Eli Zaretskii To: Kenichi Handa CC: 3452@debbugs.gnu.org, cyd@stupidchicken.com In-reply-to: (message from Kenichi Handa on Mon, 08 Jun 2009 17:10:27 +0900) Subject: Re: bug#3452: 23.0.94; display Reply-to: Eli Zaretskii References: <877hzoogc1.fsf@cyd.mit.edu> Message-Id: Date: Mon, 08 Jun 2009 04:44:50 -0400 > From: Kenichi Handa > CC: 3452@emacsbugs.donarmstrong.com, cyd@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? From handa@m17n.org Mon Jun 8 04:57:14 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 8 Jun 2009 11:57:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,SPF_HELO_PASS autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n58Bv9gU012789 for <3452@emacsbugs.donarmstrong.com>; Mon, 8 Jun 2009 04:57:11 -0700 Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id n58Bv8Ba013054; Mon, 8 Jun 2009 20:57:08 +0900 (JST) env-from (handa@m17n.org) Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id n58Bv7bA027948; Mon, 8 Jun 2009 20:57:07 +0900 (JST) env-from (handa@m17n.org) Received: by smtp4.aist.go.jp with ESMTP id n58Bv6Bi009734; Mon, 8 Jun 2009 20:57:06 +0900 (JST) env-from (handa@m17n.org) Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1MDdTO-00031x-Np; Mon, 08 Jun 2009 20:57:06 +0900 From: Kenichi Handa To: Eli Zaretskii CC: 3452@debbugs.gnu.org, cyd@stupidchicken.com In-reply-to: (message from Eli Zaretskii on Mon, 08 Jun 2009 04:44:50 -0400) Subject: Re: bug#3452: 23.0.94; display References: <877hzoogc1.fsf@cyd.mit.edu> Message-Id: Date: Mon, 08 Jun 2009 20:57:06 +0900 In article , Eli Zaretskii writes: > > From: Kenichi Handa > > CC: 3452@emacsbugs.donarmstrong.com, cyd@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@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)) From cyd@stupidchicken.com Mon Jun 8 07:47:38 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 8 Jun 2009 14:47:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n58ElYFL008848 for <3452@emacsbugs.donarmstrong.com>; Mon, 8 Jun 2009 07:47:35 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 2704F57E24D; Mon, 8 Jun 2009 10:47:38 -0400 (EDT) From: Chong Yidong To: Kenichi Handa Cc: Eli Zaretskii , 3452@debbugs.gnu.org Subject: Re: bug#3452: 23.0.94; display References: <877hzoogc1.fsf@cyd.mit.edu> Date: Mon, 08 Jun 2009 10:47:38 -0400 In-Reply-To: (Kenichi Handa's message of "Mon, 08 Jun 2009 20:57:06 +0900") Message-ID: <87prdeaik5.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Kenichi Handa 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. From cyd@stupidchicken.com Tue Jun 9 11:00:42 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 9 Jun 2009 18:00:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n59I0c3A007559 for <3452@emacsbugs.donarmstrong.com>; Tue, 9 Jun 2009 11:00:40 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 7189757E21C; Tue, 9 Jun 2009 14:00:43 -0400 (EDT) From: Chong Yidong To: Kenichi Handa Cc: Eli Zaretskii , 3452@debbugs.gnu.org Subject: Re: bug#3452: 23.0.94; display References: <877hzoogc1.fsf@cyd.mit.edu> Date: Tue, 09 Jun 2009 14:00:43 -0400 In-Reply-To: (Kenichi Handa's message of "Mon, 08 Jun 2009 20:57:06 +0900") Message-ID: <87fxe9p9ro.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Kenichi Handa 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. From handa@m17n.org Tue Jun 9 17:36:07 2009 Received: (at 3452) by emacsbugs.donarmstrong.com; 10 Jun 2009 00:36:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.1 required=4.0 tests=AWL,HAS_BUG_NUMBER, IMPRONONCABLE_2,MURPHY_DRUGS_REL8,SPF_HELO_PASS autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5A0a2Yh032059 for <3452@emacsbugs.donarmstrong.com>; Tue, 9 Jun 2009 17:36:04 -0700 Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id n5A0Zxva009913; Wed, 10 Jun 2009 09:35:59 +0900 (JST) env-from (handa@m17n.org) Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id n5A0Zxcw002204; Wed, 10 Jun 2009 09:35:59 +0900 (JST) env-from (handa@m17n.org) Received: by smtp2.aist.go.jp with ESMTP id n5A0ZxbH000316; Wed, 10 Jun 2009 09:35:59 +0900 (JST) env-from (handa@m17n.org) Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1MEBnL-00086l-13; Wed, 10 Jun 2009 09:35:59 +0900 From: Kenichi Handa To: Chong Yidong CC: eliz@gnu.org, 3452@debbugs.gnu.org In-reply-to: <87fxe9p9ro.fsf@cyd.mit.edu> (message from Chong Yidong on Tue, 09 Jun 2009 14:00:43 -0400) Subject: Re: bug#3452: 23.0.94; display References: <877hzoogc1.fsf@cyd.mit.edu> <87fxe9p9ro.fsf@cyd.mit.edu> Message-Id: Date: Wed, 10 Jun 2009 09:35:59 +0900 In article <87fxe9p9ro.fsf@cyd.mit.edu>, Chong Yidong writes: > Kenichi Handa 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@m17n.org From cyd@stupidchicken.com Wed Jun 10 07:19:59 2009 Received: (at 3452-done) by emacsbugs.donarmstrong.com; 10 Jun 2009 14:19:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5AEJtCm019850 for <3452-done@emacsbugs.donarmstrong.com>; Wed, 10 Jun 2009 07:19:57 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 41ADB57E21A; Wed, 10 Jun 2009 10:20:01 -0400 (EDT) From: Chong Yidong To: Kenichi Handa Cc: eliz@gnu.org, 3452-done@debbugs.gnu.org Subject: Re: bug#3452: 23.0.94; display References: <877hzoogc1.fsf@cyd.mit.edu> <87fxe9p9ro.fsf@cyd.mit.edu> Date: Wed, 10 Jun 2009 10:20:01 -0400 In-Reply-To: (Kenichi Handa's message of "Wed, 10 Jun 2009 09:35:59 +0900") Message-ID: <87ocswdvce.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> The patch works very well. Could you check it in? Thanks. > > Ok, done. Thanks. From unknown Tue Jun 24 19:08:24 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: $requester Subject: Internal Control Message-Id: bug archived. Date: Thu, 16 Jul 2009 14:24:10 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A log time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator