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

[martin rudalics]

>> I don't know.  IIUC most iterator functions never return something
>> useful.
>
> Because there was no need.  Now there is.

But hardly anyone delving into move_it_to wants to know that it returns
the maximum length of any row it encountered.  So I'm quite reluctant to
break this tradition.

> Adding a member to 'struct it' has the downside of enlarging the
> structure, which slows down any code that copies such structs.  We are
> going to punish all the users for the benefit of just one.  So I think
> we should avoid that.

How about making this static in xdisp.c like last_max_ascent and
last_height?

>>  >> +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.
>
> Then how about text-pixel-size?

This would imply that I had to accept any text as argument.  Maybe
`window-buffer-text-pixel-size' would be most accurate - after all it's
about a window, its buffer, and (part of) that buffer's text.

> move_it_to might overshoot in those cases, i.e. you get more pixels
> than strictly needed.

I earlier tried (line_bottom_y (&it)) as the return value but that
simply added the last line's height twice.  Anyway, in my limited
experience with this function it's still better to overshoot than
getting too few pixels.  The thing that troubled me most was this

             If TO_X is not specified, use a TO_X of zero.  The reason
             is to make the outcome of this function more predictable.
             If we didn't use TO_X == 0, we would stop at the end of
             the line which is probably not what a caller would expect
             to happen.

which caused me to exit a line too early and consequently not show the
end of the last visible line of a window when it was the longest one.  I
eventually fixed this by calling move_it_to with to_x equal to
MOST_POSITIVE_FIXNUM.  Yet, having to_x equal -1 _not_ go to
last_visible_x seems quite arbitrary to me.

> But OTOH, I see no way of asking for more
> specific limits in these cases, nor a use-case where that could be
> needed.  So I guess we are okay until someone hollers.

I think so too.  I didn't try testing any special cases and IIUC nobody
tried my patch so far.

martin