[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Handling invisible text in bidirectional display
From: |
Eli Zaretskii |
Subject: |
Re: Handling invisible text in bidirectional display |
Date: |
Sat, 16 Jan 2010 22:32:16 +0200 |
> 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.
- Handling invisible text in bidirectional display, Eli Zaretskii, 2010/01/16
- Re: Handling invisible text in bidirectional display, martin rudalics, 2010/01/16
- Re: Handling invisible text in bidirectional display,
Eli Zaretskii <=
- Re: Handling invisible text in bidirectional display, martin rudalics, 2010/01/17
- Re: Handling invisible text in bidirectional display, Eli Zaretskii, 2010/01/17
- Re: Handling invisible text in bidirectional display, martin rudalics, 2010/01/18
- Re: Handling invisible text in bidirectional display, Eli Zaretskii, 2010/01/18
- Re: Handling invisible text in bidirectional display, martin rudalics, 2010/01/18
- Re: Handling invisible text in bidirectional display, Eli Zaretskii, 2010/01/18
Re: Handling invisible text in bidirectional display, David Kastrup, 2010/01/16