bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B

[martin rudalics <rudalics@gmx.at>]

 >> +  /* Maximum x pixel position encountered within a display line.  */
 >> +  int max_current_x;
 >
 > Adding a struct member for the sake of just one user sounds
 > unjustified.  Can we instead make move_it_to accumulate the value
 > internally and return it?

I don't know.  IIUC most iterator functions never return something
useful.  And if one wants to glue together the results of subsequent
calls of move_it_to, it might make sense to not reset the value
internally.

 > In any case, the comment is inaccurate, since the value is accumulated
 > across all the display lines traversed by the iterator, not computed
 > per display line.

Would "within any line traversed by the iterator" be better?

 >> +DEFUN ("window-buffer-pixel-size", Fwindow_buffer_pixel_size, Swindow_buffer_pixel_size, 0, 5, 0,
 >
 > Why not window-text-pixel-size?  The "buffer" part doesn't belong
 > here, I think.

Since I also look at buffer portions outside the window, such a term
wouldn't be very accurate either.

 > "Lines starting below Y_LIMIT" is ambiguous.  I suggest
 >
 >   Lines whose y-coordinate is beyond Y_LIMIT will not be scanned.

OK.

 >> +Since calculating the pixel-height of a large buffer can take some time,
 >> +it makes sense to specify this argument if the size of the buffer is
 >> +unknown.  */)
 >
 > The doc string keeps silent about arguments FROM and TO.

... because I only added them later on ;-) Initially I always scanned
from `point-min' to min (`point-max', y_limit) but later I noticed that
with side-by-side windows it makes sense to start at `window-start'.

 >> +  /* Actually, we never want move_it_to stop at to_x.  But to make sure
 >> +     that move_it_in_display_line_to always moves far enough, we set it
 >> +     to MOST_POSITIVE_FIXNUM and specify MOVE_TO_X.  */
 >> +  move_it_to (&it, end, MOST_POSITIVE_FIXNUM, max_y, -1,
 >> +	      MOVE_TO_POS | MOVE_TO_X | MOVE_TO_Y);
 >
 > Did you test what this does when END is covered by a display string?

No.  I didn't try invisible text and other atrocities either.  In fact,
I never experimented with a non-ZV end position so far.  Which problems
do you see?

martin