Re: Can we make set_point_both less expensive?

[martin rudalics <rudalics@gmx.at>]

 > For me, a bad interaction is one where p-r-f followed by redisplay
 > followed by p-r-f followed by redisplay doesn't give the right answer.

OK.

 > But with something like `cursor-intangible', there will surely be cases
 > where that can happen.  E.g. imagine you scroll to a part of the buffer
 > that's got a cursor-intangible element: redisplay will move point to
 > a visible (and intangible) part of the buffer, then run p-r-f which
 > moves point outside of the window, after which redisplay has two
 > choices: either it decides to scroll to where point is (which would be
 > wrong, since we've just scrolled so we should move point rather than
 > scroll), or it moves point back into the intangible element.

I suppose we agree that when the entire window text is intangible, no
"classic" solution to this problem exists.  So a solution will exist iff
the intangible area leaves some tangible text above or below.  Handling
the intangible property makes IMO sense only after redisplay has
determined the start/point/end positions of the window.  Then the second
incarnation of p-r-f will have to move the window's point to the start
or end of the intangible area, whichever is nearer to the window point
established by redisplay.  Or do I miss something?

 > Implement a new `cursor-intangible' property, by having p-r-f move point
 > away from text with that property.

Strictly spoken I see no reason why the display engine should not handle
that property by itself.  Someone would have to handle the scroll
margins too when determining on which side of the area to move point.
And someone would have to remember the old window start position to
ensure that scrolling actually makes some progress.  So in the worst
case we would probably have to come up with a "non-classic" solution
anyway where point ends up outside the window.

martin