From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.bugs Subject: bug#3452: 23.0.94; display Date: Mon, 08 Jun 2009 10:51:14 +0900 Message-ID: References: <877hzoogc1.fsf@cyd.mit.edu> Reply-To: Kenichi Handa , 3452@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1244427458 3725 80.91.229.12 (8 Jun 2009 02:17:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Jun 2009 02:17:38 +0000 (UTC) Cc: 3452@emacsbugs.donarmstrong.com To: Chong Yidong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 08 04:17:35 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MDUQY-0007un-Ak for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Jun 2009 04:17:34 +0200 Original-Received: from localhost ([127.0.0.1]:58520 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDUQV-0001Op-D5 for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Jun 2009 22:17:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDUQR-0001Oj-98 for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2009 22:17:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDUQM-0001KN-AN for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2009 22:17:26 -0400 Original-Received: from [199.232.76.173] (port=40295 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDUQM-0001K1-2t for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2009 22:17:22 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:57552) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MDUQL-0002Fe-Jt for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2009 22:17:21 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n582HJwr016873; Sun, 7 Jun 2009 19:17:19 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n58203oP013397; Sun, 7 Jun 2009 19:00:03 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Kenichi Handa Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 08 Jun 2009 02:00:03 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 3452 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 3452-submit@emacsbugs.donarmstrong.com id=B3452.124442588312555 (code B ref 3452); Mon, 08 Jun 2009 02:00:03 +0000 Original-Received: (at 3452) by emacsbugs.donarmstrong.com; 8 Jun 2009 01:51:23 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-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 Original-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) Original-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) Original-Received: by smtp4.aist.go.jp with ESMTP id n581pEVq016566; Mon, 8 Jun 2009 10:51:14 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1MDU14-0000xn-M7; Mon, 08 Jun 2009 10:51:14 +0900 In-reply-to: <877hzoogc1.fsf@cyd.mit.edu> (message from Chong Yidong on Sat, 06 Jun 2009 23:47:26 -0400) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Sun, 07 Jun 2009 22:17:26 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:28547 Archived-At: 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