> > For instance, if you have this text:
> > r2l contents is embeded here [RLE] R2L CONTENTS [PDF].
> > the current bidi code generates glyphs in this visual order:
> > ... here [PDF] STNETNOC L2R [RLE].
> Yes, this is intentional: when these formatting characters are
> revealed, they should enclose the text they affect.
There is another way to enclose the text:
... here [RLE] STNETNOC L2R [PDF].
I don't know which is good. Does the current code conform
to "5.2 Retaining Format Codes" of UAX#9?
> > and that means we can't compose [PDF] with the following ".".
> Hmm.. I thought composition works on the buffer text level, i.e. it
> examines characters in logical order (even if it sometimes does it
> backwards). So you should be able to compose PDF with the period that
> follows it, no?
The current code never composes characters striding over
In the above example, when bidi_move_to_visually_next sets
IT's position at [PDF], scan direction is changed, and thus
composition_compute_stop_pos is called to find the next
stop. In this case, composition_compute_stop_pos scans
buffer backward, and thus it never finds the sequence
> > And what should we do when the last character is one of
> > formatting characters?
> > At last, it seems like an abuse of composition in this case
> > because those formatting characters don't construct a
> > grapheme cluster with the following char.
> OK, I'm convinced. Let's go with the hide mode instead. I hope the
> need for one more C-f/C-b will not be confusing. Maybe we should
> modify cursor motion commands to automatically move past these
> characters? What do other application do, for example OpenOffice?
In OpenOffice (3.2), we must type Left key twice to move
past one formatting characters. Gedit is the same.