Re: Can we make set_point_both less expensive?

[martin rudalics]

> If the flag that forced redisplay to honor WS is still set, then (4)
> won't happen, I think.  Instead, redisplay will recenter point in the
> window.

Recentering point during scrolling constitutes the worst of all worlds
in my experience.

> Good luck implementing that!  We already have a thick forest of
> conflicting goals in that area,

We can always close our eyes and hope that moving further goals to
`pre-redisplay-function' won't thicken that forest even more so.

> due to requirements for scroll-margin,
> scroll-*-aggressively, scroll-conservatively, and scroll-step.

I've never been able to understand these anyway.  Here, I only want to
keep point from recentering.  One option for that would be all I need.

>> Note that (3) means we have to search all text/overlay properties of
>> every window that gets redisplayed for the sole purpose of detecting the
>> presence of intangible text.  In my estimate 99.99% of our windows don't
>> contain such text.
>
> We already do precisely that, just in another place, where we move
> point.

In adjust_point_for_property?

> That was the issue that triggered this thread in the first
> place.  Stefan's intent is to lower the number of such searches, by
> only doing that for position of point that will be actually shown to
> the user, whereas today we do that for interim positions that will
> never be displayed.

The display engine knows what will be displayed where.  Elisp never
will.  I see little reason to delegate to Elisp the task of finding a
position where to show the cursor.

martin