Re: Compositions and bidi display

[Kenichi Handa]

In article <address@hidden>, Eli Zaretskii <address@hidden> 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
address@hidden