Re: Can we make set_point_both less expensive?

[martin rudalics]

>> The loop wouldn't be "an error in any case".  It would be the result of
>> an interaction of the function on the hook and the display engine.
>
> Right, but such an interaction is undesirable, so it would reflect
> a misbehavior, i.e. an error.

In my experience errors in hooks are a pain to detect and debug.  So I'd
rather try to inhibit potential misbehavior than to fix it.

> Basically, I'd want something like:
> 1- pre-redisplay-function
> 2- do redisplay
> 3- point is out of the window, so move point
> 4- pre-redisplay-function again
> 5- do redisplay again
> 6- point is out of the window again, so move point again but without
>     going through a new redisplay loop (might want to record the problem
>     in *Messages* instead)
>
> tho the exact behavior of 6 is not very important to me (as long as
> it doesn't loop indefinitely).
>
> Also, step (4) will often do nothing in which case we should be able to
> skip 5 and 6.  For that we might need to slightly change
> pre-redisplay-function by making it return whether something was changed
> or not.

I would have "4" (which presumably would happen around the time
mark_window_display_accurate is run) call a different function so that
the callee is aware of (1) whether the window's point/start/end
positions are valid and (2) the fact that redisplay might not call it
again before the end of the present redisplay cycle.

martin