From unknown Wed Jun 25 10:54:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12352: 24.2.50; Failure to compose characters in mode-line input method indicator Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Sep 2012 20:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 12352 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 12352@debbugs.gnu.org Cc: Kenichi Handa X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.134678884930099 (code B ref -1); Tue, 04 Sep 2012 20:01:02 +0000 Received: (at submit) by debbugs.gnu.org; 4 Sep 2012 20:00:49 +0000 Received: from localhost ([127.0.0.1]:38893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T8zIm-0007pP-GW for submit@debbugs.gnu.org; Tue, 04 Sep 2012 16:00:49 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35682) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T8zIi-0007pG-Qr for submit@debbugs.gnu.org; Tue, 04 Sep 2012 16:00:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8zIe-0002Hb-MO for submit@debbugs.gnu.org; Tue, 04 Sep 2012 16:00:42 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:47506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8zIe-0002HV-J4 for submit@debbugs.gnu.org; Tue, 04 Sep 2012 16:00:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8zIY-0002Hj-5F for bug-gnu-emacs@gnu.org; Tue, 04 Sep 2012 16:00:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8zIW-00029V-2Q for bug-gnu-emacs@gnu.org; Tue, 04 Sep 2012 16:00:34 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:46356) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8zIV-00028C-Jb for bug-gnu-emacs@gnu.org; Tue, 04 Sep 2012 16:00:31 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M9U00M00CU09C00@a-mtaout20.012.net.il> for bug-gnu-emacs@gnu.org; Tue, 04 Sep 2012 23:00:29 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M9U00LSPCWTR380@a-mtaout20.012.net.il>; Tue, 04 Sep 2012 23:00:29 +0300 (IDT) Date: Tue, 04 Sep 2012 23:00:39 +0300 From: Eli Zaretskii Message-id: <83ehmheexk.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -7.1 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.1 (-------) This bug report will be sent to the Bug-GNU-Emacs mailing list and the GNU bug tracker at debbugs.gnu.org. Please check that the From: line contains a valid email address. After a delay of up to one day, you should receive an acknowledgment at that address. Please write in English if possible, as the Emacs maintainers usually do not have translators for other languages. Please describe exactly what actions triggered the bug, and the precise symptoms of the bug. If you can, give a recipe starting from `emacs -Q': emacs -Q C-u C-\ hebrew-full RET Then look at the input method's indicator at the left edge of the mod= e line. It should be displayed as a single composed character with 2 diacriticals. Instead, on Windows XP, it is displayed as 3 separate characters, one after the other. (On Windows 7 Emacs displays them correctly, but that's because the font driver "composes" the diacriticals for us.) For some reason, Emacs does not compose the first and the second characters (AYIN and HIRIQ) when we display them on the mode line. But they _are_ composed when they are displayed in a buffer, just visit leim/quail/hebrew.el and search for "hebrew-full". In the debugger, I clearly see the composition in the glyph row created for buffer display: Breakpoint 5, display_line (it=3D0x82ca00) at xdisp.c:19258 19258 struct glyph_row *row =3D it->glyph_row; (gdb) n 19261 void *wrap_data =3D NULL; (gdb) pgrow TEXT: 54 glyphs 0 0: CHAR[ ] pos=3D7864 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 MB 1 8: CHAR["] pos=3D7865 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 2 16: CHAR[h] pos=3D7866 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 3 24: CHAR[e] pos=3D7867 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 4 32: CHAR[b] pos=3D7868 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 5 40: CHAR[r] pos=3D7869 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 6 48: CHAR[e] pos=3D7870 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 7 56: CHAR[w] pos=3D7871 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 8 64: CHAR[-] pos=3D7872 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 9 72: CHAR[f] pos=3D7873 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 10 80: CHAR[u] pos=3D7874 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 11 88: CHAR[l] pos=3D7875 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 12 96: CHAR[l] pos=3D7876 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 13 104: CHAR["] pos=3D7877 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 14 112: CHAR[ ] pos=3D7878 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 MB 15 120: CHAR["] pos=3D7879 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 16 128: CHAR[H] pos=3D7880 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 17 136: CHAR[e] pos=3D7881 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 18 144: CHAR[b] pos=3D7882 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 19 152: CHAR[r] pos=3D7883 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 20 160: CHAR[e] pos=3D7884 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 21 168: CHAR[w] pos=3D7885 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 22 176: CHAR["] pos=3D7886 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 23 184: CHAR[ ] pos=3D7887 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 MB 24 192: CHAR["] pos=3D7888 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 25 200: CHAR[0x5ab] pos=3D7891 blev=3D1,btyp=3DR w=3D5 a+d=3D14+4= face=3D24 MB 26 205: COMP[8 (0..1)] pos=3D7889 w=3D8 a+d=3D12+4 face=3D25 MB s= lice=3D0,0,1,0 27 213: CHAR["] pos=3D7892 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 28 221: CHAR[ ] pos=3D7893 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 MB but I see a strange single-character "composition" when the same 3 characters are displayed from a Lisp string on the mode line: Breakpoint 6, display_string (string=3D0x0, lisp_string=3D55651665, face_string=3D54827034, face_string_pos=3D0, start=3D0, it=3D0x= 82c9e0, field_width=3D0, precision=3D-1, max_x=3D0, multibyte=3D1) at x= disp.c:21887 21887 int hpos_at_start =3D it->hpos; (gdb) pp lisp_string #("=D7=A2=D6=B4=D6=AB" 0 3 (mouse-face mode-line-highlight local-ma= p (keymap (mode-line keymap ... (gdb) finish Run till exit from #0 display_string (string=3D0x0, lisp_string= =3D55651665, face_string=3D54827034, face_string_pos=3D0, start=3D0, it=3D0x= 82c9e0, field_width=3D0, precision=3D-1, max_x=3D0, multibyte=3D1) at x= disp.c:21887 0x011988d5 in display_mode_element (it=3D0x82c9e0, depth=3D8, field= _width=3D0, precision=3D-1, elt=3D55651665, props=3D56509982, risky=3D1) at= xdisp.c:20543 20543 n +=3D display_string (NULL, elt, Qnil, 0, = 0, it, Value returned is $8 =3D 3 (gdb) pgrowx it->glyph_row TEXT: 4 glyphs 0 0: CHAR[ ] str=3D35e7fb1[0] blev=3D0,btyp=3DL w=3D9 a+d=3D12= +4 face=3D1 [ 1 9: CHAR[0x5ab] str=3D3512d51[2] blev=3D1,btyp=3DR w=3D5 a+d= =3D14+4 face=3D15 MB 2 14: COMP[0 (0..0)] str=3D3512d51[1] w=3D8 a+d=3D12+4 face= =3D16 MB 3 22: CHAR[0x5e2] str=3D3512d51[0] blev=3D1,btyp=3DR w=3D8 a+d= =3D12+4 face=3D16 MB Why isn't Emacs composing these characters when they are displayed =66rom a Lisp string? If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. For information about debugging Emacs, please read the file d:/gnu/bzr/emacs/trunk/etc/DEBUG. In GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600) of 2012-09-04 on HOME-C4E4A596F7 Bzr revision: 109879 eggert@cs.ucla.edu-20120904182904-vhuzro412a8v1u= e5 Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (3.4) --no-opt --enable-checking --cflags -Id:/usr/include/libxml2 -DGLYPH_DEBUG=3D1' Important settings: value of $LANG: ENU locale-coding-system: cp1255 default enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-u C-\ h e b r - f M-x r e d=20 r C-x C-f l e i =20 q u a h e b C-s f u l l =20 =20 =20 =20 M-x C-x b M-x =20 M-x r e p o r t - e m Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Loading quail/hebrew...done Loading vc-bzr...done Mark saved where search started Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 = mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils misearch multi-isearch vc-bzr mule-util cus-sta= rt cus-load quail help-mode easymenu time-date tooltip ediff-hook vc-hoo= ks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list newcommen= t lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgia= n utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer button faces cus-face macroexp files text-properties overl= ay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process multi-tty ema= cs) From unknown Wed Jun 25 10:54:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12352: 24.2.50; Failure to compose characters in mode-line input method indicator Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Sep 2012 08:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12352 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Kenichi Handa Cc: 12352@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 12352-submit@debbugs.gnu.org id=B12352.134830222514139 (code B ref 12352); Sat, 22 Sep 2012 08:24:01 +0000 Received: (at 12352) by debbugs.gnu.org; 22 Sep 2012 08:23:45 +0000 Received: from localhost ([127.0.0.1]:48013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TFL01-0003fw-6a for submit@debbugs.gnu.org; Sat, 22 Sep 2012 04:23:45 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:33947) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TFKzw-0003fl-GD for 12352@debbugs.gnu.org; Sat, 22 Sep 2012 04:23:40 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MAQ00G00S87B400@a-mtaout23.012.net.il> for 12352@debbugs.gnu.org; Sat, 22 Sep 2012 11:21:53 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAQ00G6YSKGBA10@a-mtaout23.012.net.il>; Sat, 22 Sep 2012 11:21:53 +0300 (IDT) Date: Sat, 22 Sep 2012 11:21:41 +0300 From: Eli Zaretskii In-reply-to: <87zk4id7po.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83lig2wjqi.fsf@gnu.org> References: <87zk4id7po.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Kenichi Handa > Cc: handa@gnu.org > Date: Sat, 22 Sep 2012 13:04:03 +0900 > > In article <876279dvv7.fsf@gnu.org>, Kenichi Handa writes: > > > I think I tracked down the problem to the function > > composition_reseat_it which calls autocmp_chars. This bug > > happens when a Hebrew (or any other R2L script) syllable has > > N characters and a font selected for the last character of > > the syllable is different from a font selected for the first > > character. But, autocmp_chars was not coded to work on such > > a situation. I'm now trying to find a solution. > > I've just installed a fix to the trunk. Could you please > try it? Thanks, it works now the same in both buffer and mode-line display. I think you can close this bug now. The last character, HEBREW ACCENT OLE, is still not composed with the first two, both in the buffer display and on the mode line. But I understand that this is because that character is taken from a different font, and we don't currently support compositions for characters that come from different fonts, is that right? If I use the "Keter YG" font for Hebrew, then all 3 of the characters are composed. From unknown Wed Jun 25 10:54:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12352: 24.2.50; Failure to compose characters in mode-line input method indicator Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Oct 2019 23:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12352 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Kenichi Handa , 12352@debbugs.gnu.org Received: via spool by 12352-submit@debbugs.gnu.org id=B12352.157247696532030 (code B ref 12352); Wed, 30 Oct 2019 23:10:02 +0000 Received: (at 12352) by debbugs.gnu.org; 30 Oct 2019 23:09:25 +0000 Received: from localhost ([127.0.0.1]:51835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iPx5g-0008KX-S1 for submit@debbugs.gnu.org; Wed, 30 Oct 2019 19:09:25 -0400 Received: from giraff.fripost.org ([193.234.15.44]:42450 helo=outgoing.fripost.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iPx5f-0008KH-Fv for 12352@debbugs.gnu.org; Wed, 30 Oct 2019 19:09:23 -0400 Received: from localhost (localhost [127.0.0.1]) by outgoing.fripost.org (Postfix) with ESMTP id 0F665187EC5A; Thu, 31 Oct 2019 00:09:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=x.fripost.org; h= content-type:content-type:mime-version:user-agent:message-id :in-reply-to:date:date:references:subject:subject:from:from; s= 9df9cdc7e101629b5003b587945afa70; t=1572476957; x=1574291358; bh=/WFfuKIIYUTcRyjProbGUiVmN2qw6+NABP3tZgc7p3k=; b=DSUBHBSXIRGX rnkj4ev4mMy4RwIZckyUz0vIAgsBfXn0P9YZXn4tZ/3VHFCOcXDIYPgMvb6Owds3 8PkBunW+qrTHqyrqpuSJZ8/X7+r8drIuk/HKr0vG8HU13JpTIa8MHHwYPzsLuMaO PjrvuWRF4ZF0+PMZVdV24HrAPVgkOIGlu/lHSH3OJdHo+us2aYQdq8sNovCZPj1+ /ahLJTHWDWrFDiYkbqp3fokUXA0KK88udnDZ6ZMd3c1hQqu8Pms+rCV7vY9yyNEF nuIkxDYfm1aZEP3+tsgkUTXNjy91T0a6CfKBJCSGbBL40NZffA6PjN+vR4BIogtl Uorc4O1FTg== X-Virus-Scanned: Debian amavisd-new at fripost.org Received: from outgoing.fripost.org ([127.0.0.1]) by localhost (giraff.fripost.org [127.0.0.1]) (amavisd-new, port 10040) with LMTP id vY937nMTAwNq; Thu, 31 Oct 2019 00:09:17 +0100 (CET) Received: from smtp.fripost.org (unknown [172.16.0.6]) by outgoing.fripost.org (Postfix) with ESMTP id E4DCF187EC56; Thu, 31 Oct 2019 00:09:17 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by smtp.fripost.org (Postfix) with ESMTPSA id A0E2A59A0433; Thu, 31 Oct 2019 00:09:05 +0100 (CET) Received: from skangas by joffe.skangas.se with local (Exim 4.92) (envelope-from ) id 1iPx5D-0007Uj-4h; Thu, 31 Oct 2019 00:08:55 +0100 From: Stefan Kangas References: <87zk4id7po.fsf@gnu.org> <83lig2wjqi.fsf@gnu.org> Date: Thu, 31 Oct 2019 00:08:55 +0100 In-Reply-To: <83lig2wjqi.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 22 Sep 2012 11:21:41 +0300") Message-ID: <87y2x1vnjs.fsf@joffe.skangas.se> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.0 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.0 (--) Eli Zaretskii writes: >> From: Kenichi Handa >> Cc: handa@gnu.org >> Date: Sat, 22 Sep 2012 13:04:03 +0900 >> >> In article <876279dvv7.fsf@gnu.org>, Kenichi Handa writes: >> >> > I think I tracked down the problem to the function >> > composition_reseat_it which calls autocmp_chars. This bug >> > happens when a Hebrew (or any other R2L script) syllable has >> > N characters and a font selected for the last character of >> > the syllable is different from a font selected for the first >> > character. But, autocmp_chars was not coded to work on such >> > a situation. I'm now trying to find a solution. >> >> I've just installed a fix to the trunk. Could you please >> try it? > > Thanks, it works now the same in both buffer and mode-line display. I > think you can close this bug now. > > The last character, HEBREW ACCENT OLE, is still not composed with the > first two, both in the buffer display and on the mode line. But I > understand that this is because that character is taken from a > different font, and we don't currently support compositions for > characters that come from different fonts, is that right? If I use > the "Keter YG" font for Hebrew, then all 3 of the characters are > composed. Hi Eli, Above you suggest to close the bug, but you also report a different issue. Can this bug be closed, or should it stay open? TIA. Best regards, Stefan Kangas From unknown Wed Jun 25 10:54:38 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Eli Zaretskii Subject: bug#12352: closed (Re: bug#12352: 24.2.50; Failure to compose characters in mode-line input method indicator) Message-ID: References: <83mudhngw2.fsf@gnu.org> <83ehmheexk.fsf@gnu.org> X-Gnu-PR-Message: they-closed 12352 X-Gnu-PR-Package: emacs Reply-To: 12352@debbugs.gnu.org Date: Thu, 31 Oct 2019 14:13:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1572531182-19950-1" This is a multi-part message in MIME format... ------------=_1572531182-19950-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #12352: 24.2.50; Failure to compose characters in mode-line input method in= dicator which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 12352@debbugs.gnu.org. --=20 12352: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D12352 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1572531182-19950-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 12352-done) by debbugs.gnu.org; 31 Oct 2019 14:12:26 +0000 Received: from localhost ([127.0.0.1]:53930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQBBa-0005Ay-6q for submit@debbugs.gnu.org; Thu, 31 Oct 2019 10:12:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35823) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQBBW-0005Ai-29 for 12352-done@debbugs.gnu.org; Thu, 31 Oct 2019 10:12:22 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iQBBP-0008I3-Nx; Thu, 31 Oct 2019 10:12:15 -0400 Received: from [176.228.60.248] (port=4896 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iQBBP-0002hu-9H; Thu, 31 Oct 2019 10:12:15 -0400 Date: Thu, 31 Oct 2019 16:12:13 +0200 Message-Id: <83mudhngw2.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-reply-to: <87y2x1vnjs.fsf@joffe.skangas.se> (message from Stefan Kangas on Thu, 31 Oct 2019 00:08:55 +0100) Subject: Re: bug#12352: 24.2.50; Failure to compose characters in mode-line input method indicator References: <87zk4id7po.fsf@gnu.org> <83lig2wjqi.fsf@gnu.org> <87y2x1vnjs.fsf@joffe.skangas.se> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 12352-done Cc: handa@gnu.org, 12352-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Cc: Kenichi Handa , 12352@debbugs.gnu.org > Date: Thu, 31 Oct 2019 00:08:55 +0100 > > Above you suggest to close the bug, but you also report a different > issue. Can this bug be closed, or should it stay open? It should be closed (done); the issue I mention is a general (mis)feature of character compositions in Emacs, and works as designed. Thanks. ------------=_1572531182-19950-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 4 Sep 2012 20:00:49 +0000 Received: from localhost ([127.0.0.1]:38893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T8zIm-0007pP-GW for submit@debbugs.gnu.org; Tue, 04 Sep 2012 16:00:49 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35682) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T8zIi-0007pG-Qr for submit@debbugs.gnu.org; Tue, 04 Sep 2012 16:00:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8zIe-0002Hb-MO for submit@debbugs.gnu.org; Tue, 04 Sep 2012 16:00:42 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:47506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8zIe-0002HV-J4 for submit@debbugs.gnu.org; Tue, 04 Sep 2012 16:00:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8zIY-0002Hj-5F for bug-gnu-emacs@gnu.org; Tue, 04 Sep 2012 16:00:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8zIW-00029V-2Q for bug-gnu-emacs@gnu.org; Tue, 04 Sep 2012 16:00:34 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:46356) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8zIV-00028C-Jb for bug-gnu-emacs@gnu.org; Tue, 04 Sep 2012 16:00:31 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M9U00M00CU09C00@a-mtaout20.012.net.il> for bug-gnu-emacs@gnu.org; Tue, 04 Sep 2012 23:00:29 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M9U00LSPCWTR380@a-mtaout20.012.net.il>; Tue, 04 Sep 2012 23:00:29 +0300 (IDT) Date: Tue, 04 Sep 2012 23:00:39 +0300 From: Eli Zaretskii Subject: 24.2.50; Failure to compose characters in mode-line input method indicator To: bug-gnu-emacs@gnu.org Message-id: <83ehmheexk.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -7.1 (-------) X-Debbugs-Envelope-To: submit Cc: Kenichi Handa X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.1 (-------) This bug report will be sent to the Bug-GNU-Emacs mailing list and the GNU bug tracker at debbugs.gnu.org. Please check that the From: line contains a valid email address. After a delay of up to one day, you should receive an acknowledgment at that address. Please write in English if possible, as the Emacs maintainers usually do not have translators for other languages. Please describe exactly what actions triggered the bug, and the precise symptoms of the bug. If you can, give a recipe starting from `emacs -Q': emacs -Q C-u C-\ hebrew-full RET Then look at the input method's indicator at the left edge of the mod= e line. It should be displayed as a single composed character with 2 diacriticals. Instead, on Windows XP, it is displayed as 3 separate characters, one after the other. (On Windows 7 Emacs displays them correctly, but that's because the font driver "composes" the diacriticals for us.) For some reason, Emacs does not compose the first and the second characters (AYIN and HIRIQ) when we display them on the mode line. But they _are_ composed when they are displayed in a buffer, just visit leim/quail/hebrew.el and search for "hebrew-full". In the debugger, I clearly see the composition in the glyph row created for buffer display: Breakpoint 5, display_line (it=3D0x82ca00) at xdisp.c:19258 19258 struct glyph_row *row =3D it->glyph_row; (gdb) n 19261 void *wrap_data =3D NULL; (gdb) pgrow TEXT: 54 glyphs 0 0: CHAR[ ] pos=3D7864 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 MB 1 8: CHAR["] pos=3D7865 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 2 16: CHAR[h] pos=3D7866 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 3 24: CHAR[e] pos=3D7867 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 4 32: CHAR[b] pos=3D7868 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 5 40: CHAR[r] pos=3D7869 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 6 48: CHAR[e] pos=3D7870 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 7 56: CHAR[w] pos=3D7871 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 8 64: CHAR[-] pos=3D7872 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 9 72: CHAR[f] pos=3D7873 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 10 80: CHAR[u] pos=3D7874 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 11 88: CHAR[l] pos=3D7875 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 12 96: CHAR[l] pos=3D7876 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 13 104: CHAR["] pos=3D7877 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 14 112: CHAR[ ] pos=3D7878 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 MB 15 120: CHAR["] pos=3D7879 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 16 128: CHAR[H] pos=3D7880 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 17 136: CHAR[e] pos=3D7881 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 18 144: CHAR[b] pos=3D7882 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 19 152: CHAR[r] pos=3D7883 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 20 160: CHAR[e] pos=3D7884 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 21 168: CHAR[w] pos=3D7885 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 22 176: CHAR["] pos=3D7886 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 23 184: CHAR[ ] pos=3D7887 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 MB 24 192: CHAR["] pos=3D7888 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 25 200: CHAR[0x5ab] pos=3D7891 blev=3D1,btyp=3DR w=3D5 a+d=3D14+4= face=3D24 MB 26 205: COMP[8 (0..1)] pos=3D7889 w=3D8 a+d=3D12+4 face=3D25 MB s= lice=3D0,0,1,0 27 213: CHAR["] pos=3D7892 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 fac= e=3D21 MB 28 221: CHAR[ ] pos=3D7893 blev=3D0,btyp=3DL w=3D8 a+d=3D12+4 MB but I see a strange single-character "composition" when the same 3 characters are displayed from a Lisp string on the mode line: Breakpoint 6, display_string (string=3D0x0, lisp_string=3D55651665, face_string=3D54827034, face_string_pos=3D0, start=3D0, it=3D0x= 82c9e0, field_width=3D0, precision=3D-1, max_x=3D0, multibyte=3D1) at x= disp.c:21887 21887 int hpos_at_start =3D it->hpos; (gdb) pp lisp_string #("=D7=A2=D6=B4=D6=AB" 0 3 (mouse-face mode-line-highlight local-ma= p (keymap (mode-line keymap ... (gdb) finish Run till exit from #0 display_string (string=3D0x0, lisp_string= =3D55651665, face_string=3D54827034, face_string_pos=3D0, start=3D0, it=3D0x= 82c9e0, field_width=3D0, precision=3D-1, max_x=3D0, multibyte=3D1) at x= disp.c:21887 0x011988d5 in display_mode_element (it=3D0x82c9e0, depth=3D8, field= _width=3D0, precision=3D-1, elt=3D55651665, props=3D56509982, risky=3D1) at= xdisp.c:20543 20543 n +=3D display_string (NULL, elt, Qnil, 0, = 0, it, Value returned is $8 =3D 3 (gdb) pgrowx it->glyph_row TEXT: 4 glyphs 0 0: CHAR[ ] str=3D35e7fb1[0] blev=3D0,btyp=3DL w=3D9 a+d=3D12= +4 face=3D1 [ 1 9: CHAR[0x5ab] str=3D3512d51[2] blev=3D1,btyp=3DR w=3D5 a+d= =3D14+4 face=3D15 MB 2 14: COMP[0 (0..0)] str=3D3512d51[1] w=3D8 a+d=3D12+4 face= =3D16 MB 3 22: CHAR[0x5e2] str=3D3512d51[0] blev=3D1,btyp=3DR w=3D8 a+d= =3D12+4 face=3D16 MB Why isn't Emacs composing these characters when they are displayed =66rom a Lisp string? If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. For information about debugging Emacs, please read the file d:/gnu/bzr/emacs/trunk/etc/DEBUG. In GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600) of 2012-09-04 on HOME-C4E4A596F7 Bzr revision: 109879 eggert@cs.ucla.edu-20120904182904-vhuzro412a8v1u= e5 Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (3.4) --no-opt --enable-checking --cflags -Id:/usr/include/libxml2 -DGLYPH_DEBUG=3D1' Important settings: value of $LANG: ENU locale-coding-system: cp1255 default enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-u C-\ h e b r - f M-x r e d=20 r C-x C-f l e i =20 q u a h e b C-s f u l l =20 =20 =20 =20 M-x C-x b M-x =20 M-x r e p o r t - e m Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Loading quail/hebrew...done Loading vc-bzr...done Mark saved where search started Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 = mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils misearch multi-isearch vc-bzr mule-util cus-sta= rt cus-load quail help-mode easymenu time-date tooltip ediff-hook vc-hoo= ks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list newcommen= t lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgia= n utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer button faces cus-face macroexp files text-properties overl= ay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process multi-tty ema= cs) ------------=_1572531182-19950-1--