> Date: Fri, 09 Oct 2009 23:18:00 +0200 > From: Eli Zaretskii <[email protected]> > Cc: > > While there's a lot of turf to be covered yet, I thought I'd publish > the main design decisions up to this point.
I don't know if someone follows these design decisions, but in case people are interested, here's an update: > 6. Reordering of strings from `display' properties > ... > 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. After careful thought, I changed my mind about this part. Whenever the redisplay iterator finds text that is covered by a `display' text property or by an overlay with a `display', `before-string', or `after-string' property, it will not stop reordering. Instead, it will treat the entire run of text covered by the text property or overlay as a single atomic entity, and will reorder it as if it were a single special character whose name in Unicode is OBJECT REPLACEMENT CHARACTER (u+FFFC). This character's bidirectional category (Other Neutral) and other properties are designed so that it can stand for display features such as embedded images, and in particular it is reordered as appropriate for such embedded objects. This will reorder images and display strings in the same way wrt surrounding text, which I think is reasonable. It is also in line with the pre-Emacs 24 unidirectional display engine, which skipped the text covered by such properties in one go, after displaying the image or a display string specified by the property. I hope this is the last "main design decision" regarding the basic bidirectional display. Barring any unexpected events, I will soon begin implementing reordering of display strings and images, and what will be left is "just" debugging. What will remain in the design department after that is bidirectional display in buffers that are not plain text: program source files (where bidirectional scripts can be found in strings and comments) and markup languages such as HTML and XML. _______________________________________________ emacs-bidi mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-bidi
