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

[Chong Yidong]

Eli Zaretskii <address@hidden> writes:

> I'm afraid making the reordering engine aware of all text properties
> will considerably slow down redisplay, due to the need to check
> character properties very frequently.  It also runs a high risk of
> completely blending the reordering code with the display engine, which
> will make them both very hard to maintain; currently, they are clearly
> separated.

No, the lookup would be done at the redisplay engine level, not the
reordering engine level: add a new entry in it_props[] for handling a
(say) `bidi-override' text property.  Emacs would process this during
the step in redisplay where it handles other properties (like faces and
invisibility), and record the information into the iterator.  The bidi
code would take it from there.

That should not be particularly performance intensive; we are already
doing an equal or greater amount of work handling things like face
properties.

>> Then it should be easy to exploit font-lock to give reasonably correct
>> bidi segmentation, e.g. by treating font-lock-comment-face and
>> font-lock-string-face boundaries as bidi segmentation boundaries.
>
> We should be very careful with reusing font-lock as basis for
> reordering, because the user has too much knobs to control font-lock.
> For example, few of the font-lock features speed up redisplay by
> deferring fontification to a later time.  With font-lock, this just
> displays text in the default face; with reordering, it will flush
> incorrectly rendered text for a perceptible amount of time.  I'm not
> sure it's a good idea.

The fundamental issue is that correctly segmenting source code requires
knowledge of the underlying syntax.  Sure, it's possible to come up with
some hacks that "mostly" work, but font lock is already there, so we
ought to try to use it first.

For this reason, I'm not about concerned about the deferred
fontification issue: if you want Emacs to segment properly, you'd want
it to do an amount of work equivalent to font-lock anyway.