From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Compositions and bidi display Date: Fri, 30 Apr 2010 16:15:13 +0300 Message-ID: <83ljc5w07y.fsf@gnu.org> References: <3A521851-F7CC-45DB-A2ED-8348EF96D5CF@Freenet.DE> <83fx2q5w86.fsf@gnu.org> <834oj22e96.fsf@gnu.org> <837hnuys42.fsf@gnu.org> <83mxwoxo1t.fsf@gnu.org> <83d3xjxys1.fsf@gnu.org> <83r5lxw8wi.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1272633386 26639 80.91.229.12 (30 Apr 2010 13:16:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 30 Apr 2010 13:16:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 30 15:16:24 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 1O7q4t-0007Or-5R for ged-emacs-devel@m.gmane.org; Fri, 30 Apr 2010 15:16:23 +0200 Original-Received: from localhost ([127.0.0.1]:48506 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O7q4s-0000A2-4R for ged-emacs-devel@m.gmane.org; Fri, 30 Apr 2010 09:16:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O7q4n-00008s-F8 for emacs-devel@gnu.org; Fri, 30 Apr 2010 09:16:17 -0400 Original-Received: from [140.186.70.92] (port=51645 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O7q4m-00007v-0V for emacs-devel@gnu.org; Fri, 30 Apr 2010 09:16:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O7q4g-00016m-8N for emacs-devel@gnu.org; Fri, 30 Apr 2010 09:16:15 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:43602) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O7q4f-00016T-DR for emacs-devel@gnu.org; Fri, 30 Apr 2010 09:16:10 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0L1O00700XVINX00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Fri, 30 Apr 2010 16:15:16 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.126.59.39]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L1O007UGY5A6W10@a-mtaout23.012.net.il>; Fri, 30 Apr 2010 16:15:12 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:124356 Archived-At: > From: Kenichi Handa > Cc: emacs-devel@gnu.org > Date: Fri, 30 Apr 2010 21:12:04 +0900 > > > So it looks like COMPOSITION_VALID_P is the proper way of validating a > > position that is a candidate for a static composition. Is that true? > > Yes. > > > If it is true, then the end point of the static composition is given > > by the `end' argument to find_composition, > > Yes. > > > and all we need is record it in cmp_it. > > Record it for what purpose? For determining (1) whether the current iterator position is inside a composition sequence, and (2) when to look for the next possible composition sequence. Consider a buffer with 3 composition sequence indicated by Sn..En: S1..E1.......S2..E2.....|.....S3..E3 Suppose the iterator is at the position marked by |. Then the iterator does not need to consider composite characters as long as its character position is between E2 and S3 (exclusively). If it gets to between S2 and E2, then it needs to produce the composite character from S2..E2. If it goes back beyond S2, it will need to find the places S1 and E1, and if it gets beyond E3, it will need to find the next sequence, S4..E4 (not shown above). IOW, the idea is to keep track of 2 potential composition sequences, one before and one after the current iterator position, and recompute them when the iterator is placed outside the region between the start of the leftmost and the end of the rightmost one. But it looks like this idea is not going to work with automatic compositions, see below. > > This looks as if a position that is a candidate for starting a > > composition sequence should have a non-nil entry in > > composition-function-table for the character at that position, and > > that entry should specify the (relative) character position where the > > sequence might start. Is my understanding correct? > > Mostly, but not accuate. The correct one is "A position > that will be composed with the following and/or the > preceding characters should have a non-nil entry in ...". Yes, that's what I meant, but failed to express. Thanks. > > So the next stop_pos cannot be before v. Now suppose that the > > actual composition sequence is "Suvw", and we issue the next call to > > composition_compute_stop_pos at v -- are you saying that it will > > suggest that v is also a possible stop_pos, even though it is in the > > middle of a composition sequence? --- (Q1) > > Yes, that happens in Indic scripts. Actually both a line > starting with "Suvw" and a line staring with "vw" can have > different composition at BOL. But, AFAIK, all R2L scripts > (Arabic, Dhivehi, Hebrew) don't have such a charactics. So, > in a adhoc way, we can say that your (Q1) is false. So, > > > If not, then repeated calls to > > composition_compute_stop_pos in the bidi case, without calling > > composition_reseat_it in between, will just be slightly > > more expensive because they will need to examine more positions. Is > > this analysis correct? > > it is correct but just empirically. Unfortunately, this means that Q1 must be considered to be true. The reason is the following subtlety of bidi reordering: in R2L paragraphs, where the base embedding level is 1 (as opposed to zero in L2R paragraphs), the bidi iterator delivers R2L characters in their logical order, and reorders the L2R characters. (We then reverse the character order for display in append_glyph, which prepends each new glyph instead of appending it, in such paragraphs.) So, if an Indic script is embedded in an R2L paragraph, it will hit this issue, because the iterator will see Indic characters in reverse order. Is there _any_ way to precompute the length of a composition sequence when the entry is added to composition-function-table? Or is it only possible to compute the length given the text surrounding the sequence, when it is actually encountered in a buffer or string? If the latter, I see no other way except calling autocmp_chars inside composition_compute_stop_pos. This would slow down redisplay by a factor of 2 at the worst. If that turns out too expensive, we will have to introduce some mechanism to avoid computing each composition more than once. What results of the call to autocmp_chars need to be recorded in order to avoid calling it again in composition_reseat_it? > > We can use IT_CHARPOS + MAX_COMPOSITION_COMPONENTS as ENDPOS, if we > > call composition_reseat_it and composition_compute_stop_pos in the > > forward direction repeatedly, can't we? That's because, when the > > iterator is some position, we are only interested in compositions that > > cover that position. > > No. Such a way slows down the display of a buffer that has > no composition at all. For such a buffer, > composition_compute_stop_pos should set cmp_it->stop_pos to > the actual endpos so that CHAR_COMPOSED_P quickly returns > zero. It could be that having CHAR_COMPOSED_P return non-zero once every 16 characters in a buffer with no compositions at all is still the best we can do, see above.