Re: Handling invisible text in bidirectional display

[Eli Zaretskii]

> Date: Sat, 16 Jan 2010 19:43:47 +0100
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
> 
> But what should we do with overlays with a display property?

If you mean how would their characters be reordered for display, I
described that in my mail Re: "Bidirectional editing in Emacs -- main
design decisions", back in October.  I reproduce the relevant excerpt
below.

If you mean overlays with display properties in some combination with
invisible text, please describe the situation in more detail, because
I'm not sure I see the difficulty.

Here's what I wrote in the mail mentioned above:

6. Reordering of strings from `display' properties

   Strings that are values of `display' text properties and overlay
   properties are reordered individually.  This matters when such
   properties cover adjacent portions of buffer text, back to back.
   For example, PROP1 is associated with buffer positions P1 to P2,
   and PROP2 immediately follows it, being associated with positions
   P2 to P3.  The current design calls for reordering the characters
   of the strings that are the values of PROP1 and PROP2 separately.
   An alternative would be to feed them concatenated into the
   reordering algorithm, in which case the characters coming from
   PROP2 could end up displayed before (to the left) of the characters
   coming from PROP1.  However, this alternative requires a major
   surgery of several parts of the display code.  (Interested readers
   are advised to read the code of set_cursor_from_row in xdisp.c, as
   just one example.)  It's not clear what is TRT to do in this case
   anyway; I'm not aware of any other application that provides
   similar features, so there's nothing I could compare it to.  So I
   decided to go with the easier design.  If the application needs a
   single long string, it can always collapse two or more `display'
   properties into one long one.

   Another, perhaps more serious implication of this design decision
   is that strings from `display' properties are reordered separately
   from the surrounding buffer text.  IOW, production of glyphs from
   reordered buffer text is stopped when a `display' property is
   found, the string that is the property's value is reordered and
   displayed, and then the rest of text is reordered and its glyphs
   produced.  The effect will be visible, e.g., when a `display'
   string is embedded in right-to-left text in otherwise left-to-right
   paragraph text.  Again, I think in the absence of clear "prior
   art", simplicity of design and the amount of changes required in
   the existing display engine win here.