[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chong Yidong
Subject: Re: bidi-display-reordering is now non-nil by default
Date: Thu, 18 Aug 2011 13:13:40 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]