From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: RLM and LRM are composed? Date: Thu, 01 Apr 2010 21:55:49 +0900 Message-ID: References: <837hov159z.fsf@gnu.org> <83eiizy5bg.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1270127538 2536 80.91.229.12 (1 Apr 2010 13:12:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 1 Apr 2010 13:12:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 01 15:12:13 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NxKBw-0003uk-1y for ged-emacs-devel@m.gmane.org; Thu, 01 Apr 2010 15:12:12 +0200 Original-Received: from localhost ([127.0.0.1]:54938 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxKBv-0003qm-27 for ged-emacs-devel@m.gmane.org; Thu, 01 Apr 2010 09:12:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NxK7s-0001l3-5h for emacs-devel@gnu.org; Thu, 01 Apr 2010 09:08:00 -0400 Original-Received: from [140.186.70.92] (port=34038 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxK7p-0001GA-Fs for emacs-devel@gnu.org; Thu, 01 Apr 2010 09:07:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NxJwD-0001E1-FS for emacs-devel@gnu.org; Thu, 01 Apr 2010 08:55:58 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:35962) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NxJwA-0001DM-HM; Thu, 01 Apr 2010 08:55:54 -0400 Original-Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id o31Cto0L026386; Thu, 1 Apr 2010 21:55:50 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id o31CtoKF022463; Thu, 1 Apr 2010 21:55:50 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp3.aist.go.jp with ESMTP id o31CtnbR002249; Thu, 1 Apr 2010 21:55:50 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1NxJw5-0006TB-Tq; Thu, 01 Apr 2010 21:55:49 +0900 In-Reply-To: <83eiizy5bg.fsf@gnu.org> (message from Eli Zaretskii on Thu, 01 Apr 2010 10:56:03 +0300) X-detected-operating-system: by eggs.gnu.org: Solaris 9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:123015 Archived-At: In article <83eiizy5bg.fsf@gnu.org>, Eli Zaretskii writes: > > But, the detection of non-spacing mark is done by > > (= (aref char-width-table CH) 0). > Hmm.. and why is this wrong? All formatting characters has width 0 but they are not combining characters that Unicode expect to be combined with a preceding base character. > Anyway, (aref char-width-table #x200f) => 0, so it sounds like the > current detection should have worked. What am I missing? The situation is a little bit complicated. For U+200F, we set this list in the composition-function-table. (["\\c.\\c^+" 1 compose-gstring-for-graphic] [nil 0 compose-gstring-for-graphic]) This should read as follows (provided that the buffer position of U+200F is POS). (cond ((save-excursion (goto-char (1- POS)) (looking-at "\\c.\\c^+")) (compose-gstring-for-graphic (composition-get-gstring (1- POS) (mathc-end 0) ...))) (t (compose-gstring-for-graphic (composition-get-gstring POS (1+ POS) ...)))) Here as U+200F doesn't has category "^" (combining), the second condition succeeds, and compose-gstring-for-graphic tries to compose just one char U+200F. The problem here is that the original intention of the second condition is for an independent combining character not following a base character, not for a non-combining character of zero width. What compose-gstring-for-graphic does for a single character is to adjust the metrics of the glyph to display it as if it is a spacing character so that a user can edit that character easily. Please give me more time to consider the detail of the current situation. For your 2nd question: > 2. Is it a bug or a feature that composed characters don't go through > the display table? If it's a feature, what is its purpose? perhaps we should apply the display table at least to a character that is composed only by itself (i.e. one-char composition as in the above case). --- Kenichi Handa handa@m17n.org