Re: bidi-display-reordering is now non-nil by default

[Chong Yidong]

Eli Zaretskii <address@hidden> writes:

> What happens next is the redisplay engine realizes that the stop
> position was missed, so it scans back to find the last "stop position"
> preceding `E' (since there could be other text properties or overlays
> in-between), and then handles it using the handlers in it_props[]; see
> handle_stop_backwards for how this is done.  Then it can deliver `E'
> with the right attributes, and continue delivering all the successive
> characters, until it crosses some "stop position" again, either going
> forward or backward.

Thanks for the explanation; I think I understand the problem.  But if
this is a fundamental limitation, that would be extremely disappointing.
The use of HTML spans for bidi segmentation is (IIUC) fairly well-known,
and character properties are the most straightforward analog in Emacs.

Here's another rough idea: when handle_stop is computing the next stop
position, it could call another function (analogous to compute_stop_pos)
to find and record the boundary of the next bidi-segmenting character
property---i.e. a "bidi stop position".  Then the reordering function
could look at this to help figure out the segmentation breaks, thus
avoiding advancing past this position.  Would something like that work?

> Amount of work is the least of my concerns in this regard.  I'm
> worried about the effect the temporarily incorrect display will have
> on users.

I don't recall the last time I ran into a problem with deferred
font-lock.  I seriously doubt this is a real issue.