Handling invisible text in bidirectional display

Handling invisible text in bidirectional display

[Eli Zaretskii]

This is another design decision I needed to make -- how to handle
invisible text in the display engine modified to support bidirectional
text.

The current unidirectional display code simply skips all the
characters that have the invisible property (or are covered by an
overlay with such a property).  The iteration then resumes at the
first character that does not have the invisible property.  Thus,
Emacs behaves as if the invisible characters simply did not exist in
the buffer.

But with bidirectional display, the invisible property can begin
and/or end in the middle of text that is reordered for display.  For
example, suppose the buffer includes the following text (capital
letters stand for right-to-left characters):

  abcABCxyz

This would normally be displayed like this:

  abcCBAxyz

Now imagine that we have an invisible property on characters C and x.
The current code would skip C and x, and stop on y.  But because C is
encountered when moving backwards from C to A, that causes us to miss
A and B entirely and display

  abcyz

which is clearly incorrect.  There are additional complications when
embedding characters such as RLE and LRO are involved, to override the
normal visual order of characters -- in these cases, a suitably placed
invisible property can change the visual order of the surrounding
visible characters, sometimes in a prominent way.

Therefore, I decided to modify the code which skips invisible
characters, such that it will skip them in the visual order, until it
finds the first character that is outside the region covered by the
invisible property.  Note that the ``first'' visible character could
be before or after the invisible region, in the logical order.

This preserves the visual order of displayed characters and does not
miss any characters that should be visible, but it does have
consequences that are not necessarily trivial.

One consequence is that a run of invisible characters can now be split
into several non-contiguous runs.  For example, this text:

  abcABCxyz

with c and A covered by an invisible property will be displayed as

  abCBxyz

where invisible text is split in two: one after b, the other before x.

If ellipsis should be displayed instead of the invisible text, we will
now have two places with ellipsis: one instead of c, the other instead
of A.

To me, these effects seem reasonable.  MS Word behaves the same, but
it doesn't have the ellipsis feature.  And since I'm not aware of any
other application except MS Word that supports both bidirectional text
and invisible text, I don't know what other reasonable behaviors can
be programmed.  If someone knows, please tell.

Eventually, all this boils down to the question of the use-cases that
involve invisible text.  If someone can post a list of such use-cases,
I could think whether the above modification of the display code will
support them.

TIA

Re: Handling invisible text in bidirectional display

[martin rudalics]

 > If ellipsis should be displayed instead of the invisible text, we will
 > now have two places with ellipsis: one instead of c, the other instead
 > of A.

Presumably the problem with ellipses can be handled this way.  Overlays
with a before- or after-string could be handled by putting the
before-string at the first displayed character (from the right probably
for a before-string ...).  But what should we do with overlays with a
display property?

martin

Re: Handling invisible text in bidirectional display

[Eli Zaretskii]

> Date: Sat, 16 Jan 2010 19:43:47 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org, emacs-bidi@gnu.org
> 
> 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.

Re: Handling invisible text in bidirectional display

[martin rudalics]

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

I meant neither of them.  From your initial example:

 > For example, suppose the buffer includes the following text (capital
 > letters stand for right-to-left characters):
 >
 >   abcABCxyz

Suppose I put an overlay from the position between "b" and "c" to the
position between "A" and "B" (just like your invisibility property) and
give that overlay a display property, say the character "D".

 > This would normally be displayed like this:
 >
 >   abcCBAxyz

Should we now see "abDxyz", "abDAxyz", "abDCBDxyz", or something else?
Note that the "D" is quite similar to the ellipses for invisible text
you mentioned earlier.  This issue is obviously not very important -
after all an overlay is probably misplaced if its start and end are in
text displayed in different directions - but would have to be solved
somehow anyway.

BTW, I'm not even sure whether

 > The current code would skip C and x, and stop on y.  But because C is
 > encountered when moving backwards from C to A, that causes us to miss
 > A and B entirely and display
 >
 >   abcyz
 >
 > which is clearly incorrect.

_is_ "clearly incorrect".  Conversely, suppose I have the displayed text

abcCBAxyz

with `point' between "b" and "c" and `mark' between "C" and "B" - no
overlays or text properties involved.  When I now kill the region what
will show up on the kill ring - "cAB" or "cC"?

martin

Re: Handling invisible text in bidirectional display

[Eli Zaretskii]

> Date: Sun, 17 Jan 2010 09:59:17 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org, emacs-bidi@gnu.org
> 
>  >   abcABCxyz
> 
> Suppose I put an overlay from the position between "b" and "c" to the
> position between "A" and "B" (just like your invisibility property) and
> give that overlay a display property, say the character "D".
> 
>  > This would normally be displayed like this:
>  >
>  >   abcCBAxyz
> 
> Should we now see "abDxyz", "abDAxyz", "abDCBDxyz", or something else?

"abDCBxyz", I believe.  c and A are displayed as D, but the rest of
the characters should be visible.

> Note that the "D" is quite similar to the ellipses for invisible text
> you mentioned earlier.

No, it's different.  The ellipsis shows that some text is hidden, so
if we have several stretches of hidden text, it is reasonable to show
an ellipsis for each stretch.  By contrast, a display property says,
in effect, to display the string _instead_ of the entire text covered
by the overlay, so it should be displayed only once.

> BTW, I'm not even sure whether
> 
>  > The current code would skip C and x, and stop on y.  But because C is
>  > encountered when moving backwards from C to A, that causes us to miss
>  > A and B entirely and display
>  >
>  >   abcyz
>  >
>  > which is clearly incorrect.
> 
> _is_ "clearly incorrect".  Conversely, suppose I have the displayed text
> 
> abcCBAxyz
> 
> with `point' between "b" and "c" and `mark' between "C" and "B" - no
> overlays or text properties involved.  When I now kill the region what
> will show up on the kill ring - "cAB" or "cC"?

I didn't introduce a ``visual-order'' killing, so text is still killed
in the logical order.  Therefore, the characters that will be killed
and appear in the kill ring are cAB (displayed as "cBA"), and the
resulting display after killing will be "abCxyz".  Makes sense?

Re: Handling invisible text in bidirectional display

[martin rudalics]

 >> Conversely, suppose I have the displayed text
 >>
 >> abcCBAxyz
 >>
 >> with `point' between "b" and "c" and `mark' between "C" and "B" - no
 >> overlays or text properties involved.  When I now kill the region what
 >> will show up on the kill ring - "cAB" or "cC"?
 >
 > I didn't introduce a ``visual-order'' killing, so text is still killed
 > in the logical order.  Therefore, the characters that will be killed
 > and appear in the kill ring are cAB (displayed as "cBA"), and the
 > resulting display after killing will be "abCxyz".  Makes sense?

Perfectly.  But this means that with `transient-mark-mode' the region
may consist of up to three non-contiguous stretches of text on the
display as, for example, with text displayed as CBAabcFED and `point'
between B and A and `mark' between F and E.  A and F would _not_ be
highlighted, I presume?

martin

Re: Handling invisible text in bidirectional display

[Eli Zaretskii]

> Date: Mon, 18 Jan 2010 09:11:35 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org
> 
> [...] this means that with `transient-mark-mode' the region may
> consist of up to three non-contiguous stretches of text on the
> display as, for example, with text displayed as CBAabcFED and
> `point' between B and A and `mark' between F and E.  A and F would
> _not_ be highlighted, I presume?

Yes, that's right.  (In fact, region highlight already works in the
bidi version, so I just verified that 3 stretches of text are
highlighted in this case ;-) However, this is how every other
bidi-enabled application out there works, so users expect that and
should not be surprised by this.

Re: Handling invisible text in bidirectional display

[martin rudalics]

 > Yes, that's right.  (In fact, region highlight already works in the
 > bidi version, so I just verified that 3 stretches of text are
 > highlighted in this case

Does this work with mouse highlighting too?  IIRC display code handles
that specially.  So if you draw a corresponding overlay with a
`mouse-face' property there should be three stretches highlighted when
the mouse is over one of these stretches.

martin

Re: Handling invisible text in bidirectional display

[Eli Zaretskii]

> Date: Mon, 18 Jan 2010 11:39:23 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-bidi@gnu.org, emacs-devel@gnu.org
> 
>  > Yes, that's right.  (In fact, region highlight already works in the
>  > bidi version, so I just verified that 3 stretches of text are
>  > highlighted in this case
> 
> Does this work with mouse highlighting too?  IIRC display code handles
> that specially.  So if you draw a corresponding overlay with a
> `mouse-face' property there should be three stretches highlighted when
> the mouse is over one of these stretches.

Hold your horses ;-) I didn't get to the mouse yet; as I wrote
elsewhere, all the work till now is being done on a Unix text terminal
(which does not support GPM, in case you wondered).  But I did test
hl-line-mode after setting hl-line-range-function to something that
covers a small number of characters on each side of point, and it did
work as expected.  So I believe that the mouse highlight should work
as well.

Re: Handling invisible text in bidirectional display

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> This is another design decision I needed to make -- how to handle
> invisible text in the display engine modified to support bidirectional
> text.

I think a reasonable model is to display the text as if the invisible
characters are not there.

Invisibility has other consequences except display, like what cursor
positions it allows.  Have not thought about those.

-- 
David Kastrup

Re: Handling invisible text in bidirectional display

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sat, 16 Jan 2010 20:15:35 +0100
> Cc: emacs-bidi@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This is another design decision I needed to make -- how to handle
> > invisible text in the display engine modified to support bidirectional
> > text.
> 
> I think a reasonable model is to display the text as if the invisible
> characters are not there.

I think the resulting change of the visual order will surprise the
users.  It also complicates implementation, which for me is an
important downside.

> Invisibility has other consequences except display, like what cursor
> positions it allows.

For now, I have only implemented strictly logical cursor motion.  That
is, when the next character in the logical (a.k.a. reading) order is
far away on display, C-f causes the cursor jumps to that place, then
subsequent C-f's cause it move to the left.  With this cursor motion,
invisible text in a bidi buffer behaves exactly like it does in Emacs
23.

Re: Handling invisible text in bidirectional display

[Richard Stallman]

Your description of the interaction of invisible with bidi seems right
to me, but I was surprised by your response to this

    > I think a reasonable model is to display the text as if the invisible
    > characters are not there.

    I think the resulting change of the visual order will surprise the
    users.  It also complicates implementation, which for me is an
    important downside.

because I don't see a differnce between "display the text as if the
invisible characters are not there" and what you described (in the
no-ellipsis case).  What you described

    One consequence is that a run of invisible characters can now be split
    into several non-contiguous runs.  For example, this text:

      abcABCxyz

    with c and A covered by an invisible property will be displayed as

      abCBxyz

seems to agree entirely with that description.  Is there something I
have misunderstood?

However, the invisible characters do have some effect when they
generate an ellipsis.  In that case, multiple ellipses as you've
described seems right.

Re: Handling invisible text in bidirectional display

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: dak@gnu.org, emacs-bidi@gnu.org, emacs-devel@gnu.org
> Date: Sun, 17 Jan 2010 11:05:03 -0500
> 
> Your description of the interaction of invisible with bidi seems right
> to me, but I was surprised by your response to this
> 
>     > I think a reasonable model is to display the text as if the invisible
>     > characters are not there.
> 
>     I think the resulting change of the visual order will surprise the
>     users.  It also complicates implementation, which for me is an
>     important downside.
> 
> because I don't see a differnce between "display the text as if the
> invisible characters are not there" and what you described (in the
> no-ellipsis case).  What you described
> 
>     One consequence is that a run of invisible characters can now be split
>     into several non-contiguous runs.  For example, this text:
> 
>       abcABCxyz
> 
>     with c and A covered by an invisible property will be displayed as
> 
>       abCBxyz
> 
> seems to agree entirely with that description.  Is there something I
> have misunderstood?

It's just that the example I showed is a simple one, where the
distinction doesn't show.  However, in general, the bidirectional
reordering can cause simple insertion to have non-local effect on the
visual order.  This is because so-called weak characters (digits,
plus, minus, punctuation, etc.) and neutral characters (blanks, tabs,
etc.) change their directionality depending on the surrounding text.

Here's an example.  Suppose the buffer contains this text:

  ABCD(4+5)*3

(As usual, capital letters are strong right-to-left characters.)  This
text will be displayed as

  3*(5+4)DCBA

By contrast, the same text with `+' removed will display as

  3*(45)DCBA

As you see, 4 and 5 switched their visual order.  This means that if
we first remove the invisible characters and then reorder, the 4 and 5
will appear in a different order when `+' is invisible than when it is
visible.  With my suggestion, we _first_ reorder and _then_ hide
invisible characters, so the display with `+' invisible will be

  3*(54)DCBA

which I think is less surprising.

Re: Handling invisible text in bidirectional display

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> Here's an example.  Suppose the buffer contains this text:
>
>   ABCD(4+5)*3
>
> (As usual, capital letters are strong right-to-left characters.)  This
> text will be displayed as
>
>   3*(5+4)DCBA
>
> By contrast, the same text with `+' removed will display as
>
>   3*(45)DCBA
>
> As you see, 4 and 5 switched their visual order.  This means that if
> we first remove the invisible characters and then reorder, the 4 and 5
> will appear in a different order when `+' is invisible than when it is
> visible.  With my suggestion, we _first_ reorder and _then_ hide
> invisible characters, so the display with `+' invisible will be
>
>   3*(54)DCBA
>
> which I think is less surprising.

I disagree, because there is no reason for 5 and 4 to switch their order
anymore.

There also is a difference between invisibility and display properties
here: if there is a display property on a letter "x", it is hard to see
why several consecutive images should be reordered to be L->R.  Of
course, one should argue that in the presence of L->R, people should
take care to use the right "shadowed" character to match the intended
left/rightness of the image.  But I think that is not really sane.  If
we want display property material to have an explicit direction, it
should be set with properties, not by some magic derivation from the
underlying invisible text.

-- 
David Kastrup

Re: Re: Handling invisible text in bidirectional display

[Ehud Karni]

On Sun, 17 Jan 2010 21:17:35 David Kastrup wrote:
>
> I disagree, because there is no reason for 5 and 4 to switch their order
> anymore.

Eli may had a poor example but he has the correct logic.

Let me give you a better everyday example.

A table with alternate Latin and Hebrew columns, something like:
       HEB1 lat1 HEB2 lat2 HEB3 lat3
which is displayed as (in R2L reading frame):
       lat3 3BEH lat2 2BEH lat1 1BEH
Now if HEB2 and HEB3 are invisible, Eli method will show:
       lat3 lat2 lat1 1BEH
While your method will produce:
       lat1 lat2 lat3 1BEH
i.e. the columns will have changed places.

It is even more complicated when the Latin is replaced by digits.
(if lat1 is a number, Eli's method does not change, while your
method produce:  lat2 lat3 number 1BEH).

Ehud.


--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7976-561  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry

Re: Re: Handling invisible text in bidirectional display

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sun, 17 Jan 2010 21:17:35 +0100
> Cc: emacs-devel@gnu.org
> 
> >   3*(54)DCBA
> >
> > which I think is less surprising.
> 
> I disagree, because there is no reason for 5 and 4 to switch their order
> anymore.

Well, then we'll have to disagree.

> There also is a difference between invisibility and display properties
> here: if there is a display property on a letter "x", it is hard to see
> why several consecutive images should be reordered to be L->R.  Of
> course, one should argue that in the presence of L->R, people should
> take care to use the right "shadowed" character to match the intended
> left/rightness of the image.  But I think that is not really sane.  If
> we want display property material to have an explicit direction, it
> should be set with properties, not by some magic derivation from the
> underlying invisible text.

I don't understand the use-case, and without it this reads like a
charade (what "x"? which "shadowed" characters? what images?).  Please
show a complete example, then I'll be able to reason about it.

Re: Handling invisible text in bidirectional display

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>>
>> There also is a difference between invisibility and display properties
>> here: if there is a display property on a letter "x", it is hard to see
>> why several consecutive images should be reordered to be L->R.  Of
>> course, one should argue that in the presence of L->R, people should
>> take care to use the right "shadowed" character to match the intended
>> left/rightness of the image.  But I think that is not really sane.  If
>> we want display property material to have an explicit direction, it
>> should be set with properties, not by some magic derivation from the
>> underlying invisible text.
>
> I don't understand the use-case, and without it this reads like a
> charade (what "x"? which "shadowed" characters? what images?).  Please
> show a complete example, then I'll be able to reason about it.

Just find some JPG file into an Emacs buffer and look at the underlying
presentation.

-- 
David Kastrup

Re: Re: Handling invisible text in bidirectional display

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 18 Jan 2010 07:42:53 +0100
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Kastrup <dak@gnu.org>
> >>
> >> There also is a difference between invisibility and display properties
> >> here: if there is a display property on a letter "x", it is hard to see
> >> why several consecutive images should be reordered to be L->R.  Of
> >> course, one should argue that in the presence of L->R, people should
> >> take care to use the right "shadowed" character to match the intended
> >> left/rightness of the image.  But I think that is not really sane.  If
> >> we want display property material to have an explicit direction, it
> >> should be set with properties, not by some magic derivation from the
> >> underlying invisible text.
> >
> > I don't understand the use-case, and without it this reads like a
> > charade (what "x"? which "shadowed" characters? what images?).  Please
> > show a complete example, then I'll be able to reason about it.
> 
> Just find some JPG file into an Emacs buffer and look at the underlying
> presentation.

If you are talking about a display property whose value is an image,
then the discussion until now in this thread did not cover that
use-case.  At least what I wrote did not cover it.  I was talking only
about display properties whose value is a string.

Re: Handling invisible text in bidirectional display

[Stefan Monnier]

> This is another design decision I needed to make -- how to handle
> invisible text in the display engine modified to support bidirectional
> text.

Great to hear you progress on bidi support!

> Therefore, I decided to modify the code which skips invisible
> characters, such that it will skip them in the visual order, until it
> finds the first character that is outside the region covered by the
> invisible property.  Note that the ``first'' visible character could
> be before or after the invisible region, in the logical order.

It's consistent with the current behavior, so it's probably no worse
than trying to preserve the current implementation.


        Stefan

Re: Handling invisible text in bidirectional display

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 16 Jan 2010 14:56:10 -0500
> Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org
> 
> > This is another design decision I needed to make -- how to handle
> > invisible text in the display engine modified to support bidirectional
> > text.
> 
> Great to hear you progress on bidi support!

I never stopped.  Progress is slow, but steady.

Things that work so far:

 . Display of bidirectional text, including line truncation and
   continuation
 . Scrolling
 . Cursor positioning according to point
 . Text insertion and deletion
 . Left-to-right and right-to-left paragraphs, including dynamically
   determined paragraph direction
 . Horizontal cursor motion
 . Text properties and overlays that affect faces

All this works only on a text terminal for now.  I know very little
about the GUI display back-ends we support, so others will have to
come on board and make the necessary changes there, when the time
comes.

> > Therefore, I decided to modify the code which skips invisible
> > characters, such that it will skip them in the visual order, until it
> > finds the first character that is outside the region covered by the
> > invisible property.  Note that the ``first'' visible character could
> > be before or after the invisible region, in the logical order.
> 
> It's consistent with the current behavior, so it's probably no worse
> than trying to preserve the current implementation.

Thanks for the feedback.

Re: Handling invisible text in bidirectional display

[Richard Stallman]

    > Great to hear you progress on bidi support!

    I never stopped.  Progress is slow, but steady.

    Things that work so far:

Could you post a TODO list of the things not implemented?

Re: Handling invisible text in bidirectional display

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: monnier@iro.umontreal.ca, emacs-bidi@gnu.org, emacs-devel@gnu.org
> Date: Sun, 17 Jan 2010 11:04:13 -0500
> 
>     > Great to hear you progress on bidi support!
> 
>     I never stopped.  Progress is slow, but steady.
> 
>     Things that work so far:
> 
> Could you post a TODO list of the things not implemented?

I will do that in a few days, but please note that I don't have an
exhaustive list of all the jobs that need to be done, or even
something close.  Just to make such a list is a very large job which
involves examining many features for possible implicit reliance on
text direction.

What I'm trying to do is prepare some minimal infrastructure upon
which others could build more complex features and applications.  But
even for that much smaller job, the list of things to take care is
highly dynamic, because I find out about hidden problems as I go
along.  I keep notes about issues I discovered; I will use that to
generate some kind of TODO.

Re: Handling invisible text in bidirectional display

[Richard Stallman]

    > Could you post a TODO list of the things not implemented?

    I will do that in a few days, but please note that I don't have an
    exhaustive list of all the jobs that need to be done, or even
    something close.

That should be enough to help people contribute,
once this is in the Savannah repository.

Bidi TODO (was: Handling invisible text in bidirectional display)

[Eli Zaretskii]

At Richard's request, I'm posting the todo list composed out of notes
I keep while working on the bidirectional support in Emacs.  What is
already done and underwent some minimal testing is marked by "(done)".

Please note that this list is by no means complete, not even close.
I'm discovering new issues as I go along.

-------------------------------------------------------------------

* Basic display engine infrastructure

** Basic bidirectional display

*** Bidirectional iteration through display elements

  (The names below in this section are subroutines in xdisp.c)

**** next_element_from_buffer (done)

**** next_element_from_string/c_string

**** next_element_from_display_vector

  Need to decide whether to reorder the original characters of the
  ones that come out of display tables.  Maybe have an option to do
  both.

**** next_element_from_image

**** next_element_from_stretch

*** Display of text without properties (done)

*** Line truncation and continuation (done)

*** Scrolling (done)

*** Cursor positioning (done)

*** Text insertion and deletion (done)

*** Left-to-right and right-to-left paragraphs

**** Paragraph direction variable (done)

**** Dynamic determination of paragraph direction (done)

**** Support for paragraph-start and paragraph-separate that don't
begin at line beginning

*** Horizontal cursor motion (done)

*** Vertical cursor motion

  Needs a fixed current-column/move-to-column

**** Fix visual-line-mode for bidirectional text and mixed R2L/L2R lines

  Also needs a fixed current-column/move-to-column

*** Text properties and overlays

**** Properties that determine faces (done)

  This includes the `fontified' property.

**** Invisible text (in progress)

**** `display' property

***** Property value is a string

***** Property value is an image

***** Other property values

*** Selective display and ellipsis

*** Composed characters

** Terminal-specific back-ends

*** TTY back-end

  Largely done, with the single possible exception of composite
  characters (see term.c:append_composite_glyph)

*** Support reversed (R2L) glyph rows in xdisp.c:append_*

  This is a prerequisite for the GUI back-ends (below).

*** X11 back-end

*** MS-Windows back-end

*** NS back-end

* New display features specific for bidi

** Mode to show/hide LRE, RLO, PDF, and other formatting characters

** Mode to show bidirectional level of each character

** Mirrored continuation and arrow glyphs in R2L glyph rows

* Display-related subroutines

** Support bidirectional text in current-column, move-to-column, etc.

*** Many packages use these primitives: fix them for bidi

  This might need a separate solution for each one of the packages,
  depending on how it uses these primitives and for what purpose.

* Design issues

** Load bidirectional properties of characters from uni-bidi.el

  (Currently, a char-table of properties is created in C at compile
  time, independently of Unicode properties we have in uni-*.el.)

*** When to load? at dump time? upon first use?

*** Load everything at once? only for the charset being used?

** Load mirrored properties from Unicode DB

  (Currently, only ASCII characters with mirrored properties are
  supported.)

*** Same issues as with bidirectional properties above

* Applications

** UI issues in typing bidi text

  See these URLs:

    http://www-01.ibm.com/software/globalization/topics/bidiui/index.jsp
    "better tutorial on mixed directionality" in comp.windows.x.intrinsics
    http://osdir.com/ml/region.israel.ivrix.discuss/2003-05/msg00031.html
    https://bugzilla.gnome.org/show_bug.cgi?id=70451
    https://bugzilla.gnome.org/show_bug.cgi?id=136529
    https://bugzilla.gnome.org/show_bug.cgi?id=116626

** Reverse mirrored characters in input methods for bidi languages

  (Note: Some localized keyboards do that themselves.)

** Add a convenient way of typing formatting characters (RLO, LRE, PDF)

** Support in programming modes for bidi reordering in strings and comments

  Maybe we need special text properties?

Re: [emacs-bidi] Bidi TODO (was: Handling invisible text in bidirectional display)

[Ehud Karni]

On Fri, 22 Jan 2010 15:41:17 Eli Zaretskii <eliz@gnu.org> wrote:
>
> At Richard's request, I'm posting the todo list composed out of notes
> I keep while working on the bidirectional support in Emacs.  What is
> already done and underwent some minimal testing is marked by "(done)".

Just a reminder for later stage - operations that need bidi adjustments.

Text search (simple search-forward/re-search-forward and isearch).

`rectangle' operations (the whole rect.el).


Ehud.


--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7976-561  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry

Re: Handling invisible text in bidirectional display

[Kenichi Handa]

In article <83tyulbwl2.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> Things that work so far:

>  . Display of bidirectional text, including line truncation and
>    continuation
>  . Scrolling
>  . Cursor positioning according to point
>  . Text insertion and deletion
>  . Left-to-right and right-to-left paragraphs, including dynamically
>    determined paragraph direction
>  . Horizontal cursor motion
>  . Text properties and overlays that affect faces

> All this works only on a text terminal for now.  I know very little
> about the GUI display back-ends we support, so others will have to
> come on board and make the necessary changes there, when the time
> comes.

I'd like to help Arabic/Hebrew OpenType font support.
Actually, the underlining m17n-lib already supports it.  How
can I get your latest code by bzr?

---
Kenichi Handa
handa@m17n.org

Re: Handling invisible text in bidirectional display

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: monnier@iro.umontreal.ca, emacs-bidi@gnu.org, emacs-devel@gnu.org
> Date: Mon, 18 Jan 2010 10:27:57 +0900
> 
> I'd like to help Arabic/Hebrew OpenType font support.

Thanks.  I will need your help with composed characters as well, I
think.

> How can I get your latest code by bzr?

It's on a local branch only, for now.  The best way would be to have a
public branch on Savannah.  I'm waiting for Stefan and Yidong to
decide how to arrange the branches for Emacs 24.  Once they decide, it
should be a simple matter of a single bzr command.

If you don't want to wait, I guess I can send you a patch (prepared
with "bzr send") to let you reconstruct my branch.  I will also need
to tell you how to find the necessary information in the glyph row
struct.

Re: Handling invisible text in bidirectional display

[Kenichi Handa]

In article <83y6jw6p0m.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > How can I get your latest code by bzr?

> It's on a local branch only, for now.  The best way would be to have a
> public branch on Savannah.  I'm waiting for Stefan and Yidong to
> decide how to arrange the branches for Emacs 24.  Once they decide, it
> should be a simple matter of a single bzr command.

Ok.  I'll wait for that.

> I will also need to tell you how to find the necessary
> information in the glyph row struct.

Sorry, but I don't know that much about 'struct glyph_row'.
All my work has been down without investigatng it in detail.

---
Kenichi Handa
handa@m17n.org

Re: Handling invisible text in bidirectional display

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Cc: monnier@iro.umontreal.ca, emacs-bidi@gnu.org, emacs-devel@gnu.org
> Date: Mon, 18 Jan 2010 16:40:15 +0900
> 
> > I will also need to tell you how to find the necessary
> > information in the glyph row struct.
> 
> Sorry, but I don't know that much about 'struct glyph_row'.
> All my work has been down without investigatng it in detail.

No need for any detailed investigation.  There's a flag there now that
you will need to consult, it tells you whether the glyphs in the row
are reversed (for paragraphs whose base direction is R2L).  That's
about it.  (There are a few more flags and values in struct glyph, but
that can wait for later.)

Re: Handling invisible text in bidirectional display

[Kenichi Handa]

In article <E1NWnPC-0008Vx-NO@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > From: Kenichi Handa <handa@m17n.org>
> > Cc: monnier@iro.umontreal.ca, emacs-bidi@gnu.org, emacs-devel@gnu.org
> > Date: Mon, 18 Jan 2010 16:40:15 +0900
> > 
> > > I will also need to tell you how to find the necessary
> > > information in the glyph row struct.
> > 
> > Sorry, but I don't know that much about 'struct glyph_row'.
> > All my work has been down without investigatng it in detail.

> No need for any detailed investigation.  There's a flag there now that
> you will need to consult, it tells you whether the glyphs in the row
> are reversed (for paragraphs whose base direction is R2L).  That's
> about it.  (There are a few more flags and values in struct glyph, but
> that can wait for later.)

Ok, anyway I'll wait for your code being available by bzr.

---
Kenichi Handa
handa@m17n.org