Re: Can we make set_point_both less expensive?

[martin rudalics <rudalics@gmx.at>]

 > This will only work if pre-redisplay-function is called in a way that
 > guarantees it will catch the position of point after the previous
 > command.

This command, I presume.

 > Another, related, requirement is that we never call
 > pre-redisplay-function when point is in a position that is not
 > supposed to be visible by the user.

Do you mean invisible text here?

 > Overall, it sounds like a non-trivial deviation from the original
 > purpose of pre-redisplay-function, as I understand it.
 >
 >> Whether you consider it as "redisplay" or not is another question,
 >
 > I don't consider pre-redisplay-function part of redisplay.  Martin was
 > clearly talking about redisplay, so I answered in kind.

Redisplay happens in cycles where a subsequent cycle (and maybe also
some input that arrived in between) can invalidate what happened before.
And IMO certain things that happen at top level like making the selected
window's buffer current or adjusting point in adjust_point_for_property
are part of redisplay too.  Here we disagree, obviously.

 > What I _am_ saying is that only redisplay, in its last part, knows
 > where the cursor will be positioned.

Precisely; provided it runs to completion.

 >> but when I say "redisplay" in this thread I mean the C part that
 >> fills & uses the glyph matrices
 >
 > That part of redisplay doesn't yet know where the cursor will be.
 > Cursor positioning happens after that.

And sometimes even after a first redisplay, if I can trust my eyes.

martin