GNU bug report logs - #28936
move_it_in_display_line_to returns MOVE_POS_MATCH_OR_ZV before ZV

Previous Next

Package: emacs;

Reported by: Keith David Bershatsky <esq <at> lawlist.com>

Date: Sun, 22 Oct 2017 03:04:01 UTC

Severity: normal

Tags: wontfix

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Keith David Bershatsky <esq <at> lawlist.com>
Cc: 28936 <at> debbugs.gnu.org
Subject: bug#28936: move_it_in_display_line_to returns MOVE_POS_MATCH_OR_ZV before ZV
Date: Sun, 22 Oct 2017 17:10:17 +0300
> Date: Sat, 21 Oct 2017 20:02:58 -0700
> From: Keith David Bershatsky <esq <at> 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.




This bug report was last modified 6 years and 137 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.