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

[Eli Zaretskii <eliz@gnu.org>]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Date: Thu, 18 Aug 2011 13:13:40 -0400
> 
> Eli Zaretskii <eliz@gnu.org> 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.

What's wrong with using the `display' property with a special value,
as I suggested a few mails ago?  It _is_ a character property, isn't
it?

> 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?

Yes.  But using the `display' property means fewer changes, because we
already look for it during bidi iteration, and because we do almost
the same as needed here to reorder display strings.

> > 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.

??? Set jit-lock-defer-time to something like 2, then visit xdisp.c,
scroll, and watch the fun.

It's not a "problem", deferred font-lock is _supposed_ to work like
that.  Except that what is tolerable for font-lock might not be for
display reordering.