bug#28936: move_it_in_display_line_to returns MOVE_POS_MATCH_OR_ZV before ZV

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 21 Oct 2017 20:02:58 -0700
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> 1.  `move_it_in_display_line' could use an additional comment at the outset to let readers know that it is not compatible with moving to X in a horizontal scrolling and/or truncate lines situation.  The existing commentary that it was intended for external use was insufficient to deter me, and it required a learning curve on my part to better understand its limited potential use.

More commentary can never do any harm, but the incompatibility you
describe is news to me.  Can you show a recipe in "emacs -Q" that
would demonstrate this issue?  Or show a complete code snippet,
starting with start_display or init_iterator, where this issue
happens?

> 2.  When IT is on the last line in the buffer containing a few or more characters, `move_it_in_display_line_to' stops short of the target X and erroneously returns MOVE_POS_MATCH_OR_ZV when used as follows.  I have display-line-numbers set to a non-nil value in the event that makes a difference.  There is nothing special in terms of text-properties or overlays present in the buffer.
> 
>     int target_x = [Some arbitrary X that is a few characters before ZV.];
> 
>     move_it_in_display_line_to (it, ZV, target_x, MOVE_TO_POS | MOVE_TO_X);

You don't show how the value of 'it' was set up before this call, so
it's hard to look into this issue.  I can only tell that I've reviewed
all the code paths that lead to MOVE_POS_MATCH_OR_ZV being returned,
and they all seem to be conditioned either on reaching the position or
hitting ZV.  Maybe I missed something, but without a complete code
snippet that's the best I could do.

> The workaround is to compare the result of MOVE_POS_MATCH_OR_ZV with IT_CHARPOS to ensure that we are really at a ZV situation.

MOVE_POS_MATCH_OR_ZV doesn't necessarily mean you are at ZV, you could
also be at POS or after it.