comparison src/xdisp.c @ 109891:373abedd1f02

merge from upstream

109888:fd080c6fcd86

   well, empty.  On text terminals, these special glyphs are simply
   blank characters.  On graphics terminals, there's a single stretch
   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.  */

#include <config.h>
#include <stdio.h>
#include <limits.h>
#include <setjmp.h>

109891:373abedd1f02

   well, empty.  On text terminals, these special glyphs are simply
   blank characters.  On graphics terminals, there's a single stretch
   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.

   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>
#include <limits.h>
#include <setjmp.h>