From: Kenichi Handa <handa@m17n.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Compositions and bidi display
Date: Fri, 30 Apr 2010 15:06:11 +0900 [thread overview]
Message-ID: <tl76339h3u4.fsf@m17n.org> (raw)
In-Reply-To: <83d3xjxys1.fsf@gnu.org> (message from Eli Zaretskii on Wed, 28 Apr 2010 20:38:54 +0300)
In article <83d3xjxys1.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> > The condition should be "until it reaches a character that
> > should never be composed with the currently looking
> > character".
> That is the condition I'm looking for. But how to code it? Is the
> code in find_automatic_composition a good starting point?
No. The checking of possibility of composing characters at
a specific position is done within
composition_compute_stop_pos. What we need now is where we
should stop searching in composition_compute_stop_pos.
In the case of "english HEBREW TEXT text" (lowercases are
l2r characters, upppercases are r2l characters),
get_next_display_element starts from the first "e" and
proceeds to the first " " (stage 1), then jumps to the last
"T" and proceeds back to the first "H" (stage 2), then jumps
to the last " " and proceeds to the last "t" (stage 3).
When composition_compute_stop_pos is called in stage 1,
ENDPOS should be the first " " because searching far is
useless (we may have to compose some of "TEXT" before
composing some of "HEBREW"). When
composition_compute_stop_pos is called in stage 2, ENDPOS
should be the first "H" because searching far back is
useless, and so on.
Note that composition_compute_stop_pos just finds a stop
position to check, and the actual checking and composing is
done by composition_reseat_it which is called by
CHAR_COMPOSED_P. But composition_reseat_it also needs
ENDPOS because when that funciton finds that there's no need
of composition at the stop position, it calls
composition_compute_stop_pos to update the next stop
position.
> > We may be able to simplify that condition to
> > "until it reaches a character in the different bidi level
> > (or chunk)".
> But that could be very far back.
Isn't it possible to record where the current bidi-run
started while you scan a buffer in
bidi_get_next_char_visually?
> I would really like to avoid going too far back, just to
> find out whether we reached a composition sequence,
We don't have to re-calculate ENDPOS each time. It must be
updated only when we pass over bidi boundary. Consider the
above example case ("english ...").
> because (again AFAIU) the length of most such sequences is
> just a few characters. Is it correct that searching back
> MAX_AUTO_COMPOSITION_LOOKBACK characters is enough?
No.
> If MAX_AUTO_COMPOSITION_LOOKBACK is not the right number, then how
> long can a composition sequence be?
It is MAX_COMPOSITION_COMPONENTS (16), but here it's not
relevant. What we need is to find where in a buffer (before
the scan reaches ENDPOS) next composition will happen. And,
to perform it efficiently, giving a proper ENDPOS is
necessary.
> Another idea would be to call composition_compute_stop_pos repeatedly,
> starting from the last cmp_it->stop_pos, until we find the last
> stop_pos before the current iterator position, then compute the
> beginning and end of the composable sequence at that position, and
> record it in the iterator. Then we handle the composition when we
> enter the sequence from either end.
To move from one composition position to the next, we must
actually call autocmp_chars and find where the current
composition ends, then start searching for the next
composition. As autocmp_chars calls Lisp and all functions
to compose characters, it's so inefficient to call it
repeatedly just to find the last one.
---
Kenichi Handa
handa@m17n.org
next prev parent reply other threads:[~2010-04-30 6:06 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 20:50 bug#5977: 24.0.50; Lao HELLO is incorrectly displayed Peter Dyballa
2010-04-19 23:15 ` Jason Rumney
2010-04-20 9:14 ` Eli Zaretskii
2010-04-20 23:16 ` Jason Rumney
2010-04-20 9:06 ` Eli Zaretskii
2010-04-20 10:28 ` Peter Dyballa
2010-04-20 12:17 ` Eli Zaretskii
2010-04-23 18:31 ` Eli Zaretskii
2010-04-21 2:32 ` Kenichi Handa
2010-04-23 18:52 ` Compositions and bidi display (was: bug#5977: 24.0.50; Lao HELLO is incorrectly displayed) Eli Zaretskii
2010-04-23 20:34 ` Andreas Schwab
2010-04-23 20:43 ` Eli Zaretskii
2010-04-24 11:27 ` Eli Zaretskii
2010-04-26 2:09 ` Kenichi Handa
2010-04-26 2:38 ` Kenichi Handa
2010-04-26 11:29 ` Kenichi Handa
2010-04-26 18:40 ` Compositions and bidi display Eli Zaretskii
2010-04-27 12:15 ` Kenichi Handa
2010-04-28 3:18 ` Eli Zaretskii
2010-04-28 4:01 ` Kenichi Handa
2010-04-28 17:38 ` Eli Zaretskii
2010-04-28 22:49 ` Stefan Monnier
2010-04-29 3:12 ` Eli Zaretskii
2010-04-30 2:28 ` Kenichi Handa
2010-04-30 6:41 ` Eli Zaretskii
2010-04-30 6:06 ` Kenichi Handa [this message]
2010-04-30 7:08 ` Eli Zaretskii
2010-05-03 2:39 ` Kenichi Handa
2010-05-03 7:31 ` Eli Zaretskii
2010-05-04 9:19 ` Kenichi Handa
2010-05-04 17:47 ` Eli Zaretskii
2010-04-30 10:07 ` Eli Zaretskii
2010-04-30 12:12 ` Kenichi Handa
2010-04-30 13:15 ` Eli Zaretskii
2010-04-27 3:13 ` Compositions and bidi display (was: bug#5977: 24.0.50; Lao HELLO is incorrectly displayed) Eli Zaretskii
2010-04-27 12:26 ` Kenichi Handa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tl76339h3u4.fsf@m17n.org \
--to=handa@m17n.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.