Mercurial > emacs
diff src/xdisp.c @ 109891:373abedd1f02
merge from upstream
author | joakim@verona.se |
---|---|
date | Fri, 20 Aug 2010 22:00:00 +0200 |
parents | b6004420857b |
children | 4083ea4ca585 5a930b6b595e |
line wrap: on
line diff
--- a/src/xdisp.c Fri Aug 20 21:55:21 2010 +0200 +++ b/src/xdisp.c Fri Aug 20 22:00:00 2010 +0200 @@ -217,7 +217,26 @@ glyph with suitably computed width. Both the blanks and the stretch glyph are given the face of the background of the line. This way, the terminal-specific back-end can still draw the glyphs - left to right, even for R2L lines. */ + left to right, even for R2L lines. + + Note one important detail mentioned above: that the bidi reordering + engine, driven by the iterator, produces characters in R2L rows + starting at the character that will be the rightmost on display. + As far as the iterator is concerned, the geometry of such rows is + still left to right, i.e. the iterator "thinks" the first character + is at the leftmost pixel position. The iterator does not know that + PRODUCE_GLYPHS reverses the order of the glyphs that the iterator + delivers. This is important when functions from the the move_it_* + family are used to get to certain screen position or to match + screen coordinates with buffer coordinates: these functions use the + iterator geometry, which is left to right even in R2L paragraphs. + This works well with most callers of move_it_*, because they need + to get to a specific column, and columns are still numbered in the + reading order, i.e. the rightmost character in a R2L paragraph is + still column zero. But some callers do not get well with this; a + notable example is mouse clicks that need to find the character + that corresponds to certain pixel coordinates. See + buffer_posn_from_coords in dispnew.c for how this is handled. */ #include <config.h> #include <stdio.h>