From: Kenichi Handa <handa@m17n.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Compositions and bidi display
Date: Mon, 03 May 2010 11:39:24 +0900 [thread overview]
Message-ID: <tl7y6g1aeub.fsf@m17n.org> (raw)
In-Reply-To: <83tyqtwh7z.fsf@gnu.org> (message from Eli Zaretskii on Fri, 30 Apr 2010 10:08:00 +0300)
In article <83tyqtwh7z.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> > From: Kenichi Handa <handa@m17n.org>
> > Cc: emacs-devel@gnu.org
> > Date: Fri, 30 Apr 2010 15:06:11 +0900
> >
> > 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).
> This is only the simplest case, with just 2 embedding levels: the base
> level of the paragraph, and the (higher) level of the embedded R2L
> text. The general case is much more complex: there could be up to 60
> nested levels, and some of them could begin or end at the same buffer
> position. bidi.c handles all this complexity by means of a very
> simple algorithm, but that algorithm needs to know a lot about the
> characters traversed so far. I don't think exposing all these
> internals to xdisp.c is a good idea.
Just exposing (or creating) one function that tells where
the current bidi-run ends is enough. Is it that difficult?
> > 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.
> Right, but the same is true for the bidi iteration: I need only to
> know when to check for composition; the actual composing will be still
> done by composition_reseat_it. I just cannot assume that I always
> move linearly forward in the buffer. Therefore, it is not enough to
> have only the next stop position recorded in the iterator. I need
> more information recorded. What I'm trying to determine in this
> thread is what needs to be recorded and how to compute what's needed.
> Thanks for helping me.
I don't understand the logic of "Therefore" in the above
paragraph.
> > Isn't it possible to record where the current bidi-run
> > started while you scan a buffer in
> > bidi_get_next_char_visually?
> See above: it's tricky. The function in bidi.c that looks for the
> beginning and end of a level run relies on almost all the other
> functions in bidi.c, and it does that on the fly. The level edges are
> not recorded anywhere, except in an internal cache used to speed up
> moving back in the buffer.
Then, what we need is a function that return the value of that cache.
> > > 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.
> Why not? Isn't it true that if none of the 16 characters preceding
> the current position can start a composition sequence, then the
> current position is not inside a composition sequence?
It's true, but how does it contribute to find where to check a
composition next time?
> > > 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.
> If the buffer or string is full of composed characters, then yes, it
> would be a slowdown. Especially if the number of ``suspect'' stop
> positions is much larger than the number of actual composition
> sequences. But what else can be done, given the design of the
> compositions that doesn't let us know the sequence length without
> actually composing the character?
Isn't it faster to call bidi_get_next_char_visually
repeatedly. At least it doesn't call Lisp.
And, aren't there any possibility in the current bidi code
to provide a function that gives the information I'm asking?
---
Kenichi Handa
handa@m17n.org
next prev parent reply other threads:[~2010-05-03 2:39 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
2010-04-30 7:08 ` Eli Zaretskii
2010-05-03 2:39 ` Kenichi Handa [this message]
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=tl7y6g1aeub.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.