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

[Eli Zaretskii]

> From: Chong Yidong <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Thu, 18 Aug 2011 18:44:44 -0400
> 
> Eli Zaretskii <address@hidden> writes:
> 
> > 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?
> 
> I'll have to think more about it, but I am not sure it's a good idea.
> The display property is already used for a lot of other unrelated
> purposes, like variable-width spaces.  So if you want to mark out a bidi
> segment on a stretch of text that already has other display properties
> present, you'd currently have to do some nasty merging of display specs.

I don't see any need for any merging.  We already process display
specs on before- and after-strings, and the same code can be used
here.  IOW, those other display specs will be simply processed as part
of displaying the stretch of text covered by the bidi display spec.
Since the iterator state is pushed onto the stack, I see no issues
here that need merging.  If I'm missing something, please point out
what that is or show an example where we would need to merge display
specs.

> Searching for the bidi display spec would be similarly annoying.

We already do search for display properties as part of bidi scanning,
see bidi_fetch_char and compute_display_string_pos.  It would be a
simple job to add another spec to the list of those considered
relevant by handle_display_spec, which compute_display_string_pos
calls to see if the display spec needs special handling by the bidi
iteration.  What's left is to write a next_element_from_buffer_segment
or some such that is almost an identical twin of
next_element_from_string, and a few lines of code that initialize the
bidi iterator for reordering the segment, again almost like what we
already have for display strings.

> It would be much nicer to have a separate text property specifically
> for the purpose of marking out a bidi segment.

We can do that, too, but searching for 2 different properties is more
expensive than searching for just one.

Also, it isn't clear to me how your suggestion will work if the buffer
whose segments are determined by the bidi property is also reordered
"normally", e.g. if the surrounding text includes R2L characters.  The
non-linear iteration through the surrounding text will complicate the
way we take notice of the segments that are to be reordered
separately.

> >> 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.
> 
> Then don't do that.

Users currently customize font-lock for purposes that have nothing to
do with bidi reordering.  With your suggestion, they will have two
contradicting goals for a single customization.  I don't see how they
will succeed in reconciling them.