Re: Can we make set_point_both less expensive?

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Sat, 21 Mar 2015 13:28:18 -0400
> Cc: address@hidden, address@hidden, address@hidden
> 
> >> >> > 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?
> >> > No, I mean positions traversed while "this command" is executed.  The
> >> > position shown to the user is the last one of those, but how do we
> >> > ensure that pre-redisplay-function is never run for those?
> >> Ah, I see what you mean now: the command ensures this by not causing
> >> redisplay during its execution.
> > Commands don't have full enough control to ensure that, I think.
> > Various features and customizations could trigger redisplay behind
> > their back.
> 
> Of course, but if redisplay is triggered, then the state is
> made visible.
> So if the state has "a position that is not supposed to be visible by
> the user" it's an error for the code to cause redisplay.
> The existence and use of pre-redisplay-function doesn't affect this.

I understand the theory, but I think in practice doing that in
pre-redisplay-function will not do a perfect job, perhaps not even a
good enough job.  The position of point/cursor shown to the user is
known _at_the_end_ of redisplay, not at its beginning.  the latter can
approximate the former, but only approximate.