try_cursor_movement not called?

try_cursor_movement not called?

[Po Lu]

I thought that `try_cursor_movement' was the function in charge of
updating the cursor in straightforward situations where someone pressed
C-f to move forward, and the cursor did not move outside the window.

But if I insert the following text in a buffer:

ABCDEFG

Then move point to A and press C-f, the cursor moves to "B" but
try_cursor_movement is not called.

What am I missing?

Thanks.

Re: try_cursor_movement not called?

[Eli Zaretskii]

On December 1, 2021 11:54:27 AM GMT+02:00, Po Lu <luangruo@yahoo.com> wrote:
> I thought that `try_cursor_movement' was the function in charge of
> updating the cursor in straightforward situations where someone pressed
> C-f to move forward, and the cursor did not move outside the window.
> 
> But if I insert the following text in a buffer:
> 
> ABCDEFG
> 
> Then move point to A and press C-f, the cursor moves to "B" but
> try_cursor_movement is not called.
> 
> What am I missing?
> 
> Thanks.
> 
> 

That's redisplay optimizations in action for you: there are optimizations we prefer before try_cursor_movement.

Assuming your Emacs was built with --enable-checking, invoke "M-x trace-redisplay" and look up in the code the optimizations it says it used.  (You will want to disable blink-cursor-mode and eldoc, to avoid too many meaningless trace messages.)

Re: try_cursor_movement not called?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> On December 1, 2021 11:54:27 AM GMT+02:00, Po Lu <luangruo@yahoo.com> wrote:
>> I thought that `try_cursor_movement' was the function in charge of
>> updating the cursor in straightforward situations where someone pressed
>> C-f to move forward, and the cursor did not move outside the window.
>> 
>> But if I insert the following text in a buffer:
>> 
>> ABCDEFG
>> 
>> Then move point to A and press C-f, the cursor moves to "B" but
>> try_cursor_movement is not called.
>> 
>> What am I missing?
>> 
>> Thanks.
>> 
>> 
>
> That's redisplay optimizations in action for you: there are optimizations we prefer before try_cursor_movement.
>
> Assuming your Emacs was built with --enable-checking, invoke "M-x
> trace-redisplay" and look up in the code the optimizations it says it
> used.  (You will want to disable blink-cursor-mode and eldoc, to avoid
> too many meaningless trace messages.)

Thanks.  One other question: is it valid to assume w->window_start_valid
is true inside redisplay_internal?

Re: try_cursor_movement not called?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 20:07:01 +0800
> 
> Thanks.  One other question: is it valid to assume w->window_start_valid
> is true inside redisplay_internal?

There's no such member.  Did you mean window_end_valid, perhaps?

Re: try_cursor_movement not called?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 01 Dec 2021 20:07:01 +0800
>> 
>> Thanks.  One other question: is it valid to assume w->window_start_valid
>> is true inside redisplay_internal?
>
> There's no such member.  Did you mean window_end_valid, perhaps?

Yes I did, sorry for the confusion.

Thanks.

Re: try_cursor_movement not called?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Dec 2021 20:39:26 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: emacs-devel@gnu.org
> >> Date: Wed, 01 Dec 2021 20:07:01 +0800
> >> 
> >> Thanks.  One other question: is it valid to assume w->window_start_valid
> >> is true inside redisplay_internal?
> >
> > There's no such member.  Did you mean window_end_valid, perhaps?
> 
> Yes I did, sorry for the confusion.

No, you cannot make that assumption.  window_end_valid becomes true
only if the window was successfully redisplayed and redrawn on the
glass.  If redisplay was interrupted (e.g., by new input that needs to
be processed), or we retry displaying a window after some unsuccessful
attempt, that flag will be false.

You will see that various parts of the display code test whether the
flag is true before attempting some optimizations, which should be a
clear sign that the flag could be false.

Re: try_cursor_movement not called?

[Eli Zaretskii]

> Date: Wed, 01 Dec 2021 14:49:09 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > > There's no such member.  Did you mean window_end_valid, perhaps?
> > 
> > Yes I did, sorry for the confusion.
> 
> No, you cannot make that assumption.

Btw, why did you want to assume that? what did you want to do if
window_end_valid were true?

Re: try_cursor_movement not called?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 01 Dec 2021 14:49:09 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > > There's no such member.  Did you mean window_end_valid, perhaps?
>> > 
>> > Yes I did, sorry for the confusion.
>> 
>> No, you cannot make that assumption.

> Btw, why did you want to assume that? what did you want to do if
> window_end_valid were true?

I wanted to set w->cursor_valid_p (a field I added to `struct window')
to false there, if PT > w->window_end_pos.

When w->cursor_valid_p is false, display_and_set_cursor will never
display the cursor, only erase it.

Thanks.

Re: try_cursor_movement not called?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 02 Dec 2021 14:37:46 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Btw, why did you want to assume that? what did you want to do if
> > window_end_valid were true?
> 
> I wanted to set w->cursor_valid_p (a field I added to `struct window')
> to false there, if PT > w->window_end_pos.

So you want to know whether point is beyond the window's end?  That's
possible; we do that in several places in the existing code.  It's
just slightly more complicated than a simple comparison with a known
value, and requires to use the move_it_* functions.  Basically, you
tell move_it_to to move to PT or to last_visible_y, whichever happens
first, and then examine the results: if it reached PT, then point is
inside the window, otherwise it isn't.

But beware of the underwater rocks: the window could end in some
display property, like display string or image, or in a an overlay
string.  These cases require special care with the move_it_*
functions.

Re: try_cursor_movement not called?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 02 Dec 2021 14:37:46 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Btw, why did you want to assume that? what did you want to do if
>> > window_end_valid were true?
>> 
>> I wanted to set w->cursor_valid_p (a field I added to `struct window')
>> to false there, if PT > w->window_end_pos.
>
> So you want to know whether point is beyond the window's end?  That's
> possible; we do that in several places in the existing code.  It's
> just slightly more complicated than a simple comparison with a known
> value, and requires to use the move_it_* functions.  Basically, you
> tell move_it_to to move to PT or to last_visible_y, whichever happens
> first, and then examine the results: if it reached PT, then point is
> inside the window, otherwise it isn't.

Thanks.  I looked at some of the code in try_scrolling and I think I
understand how it works now.

> But beware of the underwater rocks: the window could end in some
> display property, like display string or image, or in a an overlay
> string.  These cases require special care with the move_it_*
> functions.

However, I don't know about this.  Could you perhaps elaborate further?

Re: try_cursor_movement not called?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 02 Dec 2021 17:51:16 +0800
> 
> > But beware of the underwater rocks: the window could end in some
> > display property, like display string or image, or in a an overlay
> > string.  These cases require special care with the move_it_*
> > functions.
> 
> However, I don't know about this.  Could you perhaps elaborate further?

It's a very long story with a lot of confusing details.  Basically, if
there's any of those at the end of the window, the buffer position you
get when move_it_* functions return is not necessarily the one you
want, because those functions won't consider buffer positions while
they traverse display/overlay strings or images.  For example, if
point is "covered" by a display property, move_it_to will stop after
the display property, not at point.

I'm not sure how much of this is relevant for your use cases, though.
Just be sure to test the code when these properties are at point or at
the end of the window (if point is outside of the window).