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: Compositions and bidi display (was: bug#5977: 24.0.50; Lao HELLO is incorrectly displayed) Date: Mon, 26 Apr 2010 11:09:30 +0900 Message-ID: References: <3A521851-F7CC-45DB-A2ED-8348EF96D5CF@Freenet.DE> <83fx2q5w86.fsf@gnu.org> <834oj22e96.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 1272247718 22994 80.91.229.12 (26 Apr 2010 02:08:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 26 Apr 2010 02:08:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 26 04:08:37 2010 connect(): No such file or directory 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 1O6DkT-0000FV-4b for ged-emacs-devel@m.gmane.org; Mon, 26 Apr 2010 04:08:37 +0200 Original-Received: from localhost ([127.0.0.1]:50226 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6DkS-0002x2-Ht for ged-emacs-devel@m.gmane.org; Sun, 25 Apr 2010 22:08:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6DkM-0002ww-LR for emacs-devel@gnu.org; Sun, 25 Apr 2010 22:08:30 -0400 Original-Received: from [140.186.70.92] (port=56515 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6DkK-0002wo-7J for emacs-devel@gnu.org; Sun, 25 Apr 2010 22:08:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6DkJ-0000HU-0Z for emacs-devel@gnu.org; Sun, 25 Apr 2010 22:08:28 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:36427) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6DkE-0000Gw-IV; Sun, 25 Apr 2010 22:08:23 -0400 Original-Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id o3Q28HAG015543; Mon, 26 Apr 2010 11:08:17 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp1.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id o3Q28Hmu005719; Mon, 26 Apr 2010 11:08:17 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp1.aist.go.jp with ESMTP id o3Q28HgQ007662; Mon, 26 Apr 2010 11:08:17 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1O6DlL-0001kV-5r; Mon, 26 Apr 2010 11:09:31 +0900 In-Reply-To: <834oj22e96.fsf@gnu.org> (message from Eli Zaretskii on Fri, 23 Apr 2010 21:52:05 +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:124211 Archived-At: In article <834oj22e96.fsf@gnu.org>, Eli Zaretskii writes: > > I've just build the trunk code on GNU/Linus, and found that all > > characters displayed by composition are incorrect. > Only when bidi-display-reordering is turned on (etc/HELLO does that > automatically). > > Here's a brief explanation about control flow. > Thanks, that part was quite clear from the code. I now fixed display > of composed characters from L2R scripts when bidi-display-reordering > is set to non-nil. I've just > Where I really need help is in getting compositions to work when text > is reordered. Is it true that composition_reseat_it and its > subroutines need to see the to-be-composed characters in strict > logical order, i.e. left to right? Or can they also work if they see > the characters to be composed in the reverse order? > Also, what does this condition (in next_element_from_composition) > check? > if (it->c < 0) > { > IT_CHARPOS (*it) += it->cmp_it.nchars; > IT_BYTEPOS (*it) += it->cmp_it.nbytes; > If the meaning of the test is that there's no composition at the > iterator's position, then why do we skip some of the buffer text under > this condition? I vaguely remember that this is to avoid crash by a bug of a composition function. A composition function is written in Lisp and can be tested interactively without restarting Emacs each time. If it has a bug while testing, it may produce no glyphs for a chunk of text. In such a case, composition_update_it returns -1 and it->c is set to that return value. --- Kenichi Handa handa@m17n.org