Re: Can we make set_point_both less expensive?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 21 Mar 2015 10:58:01 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: dancol@dancol.org, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> 
>  >>   > And cursor is always set where point is, we have no other strategy for
>  >>   > positioning the cursor.
>  >>
>  >> After `scroll-left'?
>  >
>  > Yes, after scroll-left, too.  We simply put the cursor as close to
>  > point as possible.
> 
> But not necessarily _where point is_.

I was talking about the implementation.  It looks for the glyph that
is the closest to point.  It never consciously moves the cursor to any
other place.

>  >> Isn't adjust_point_for_property some sort of redisplay revisited?
>  >
>  > No.  It does nothing that is related to display.
> 
> Can't it trigger a new redisplay?

Yes, it can.  But I'm not sure it is needed.

>  >> They would determine the position of the cursor when an intangible area
>  >> starts or ends within them.
>  >
>  > Sorry, too much "they" in this sentence, I don't really understand
>  > what you are sayin, or how it is relevant to the issue at hand.
> 
> Consider the following scenario:
> 
> (1) Using the scrollbar thumb, the user scrolls window text thus
>      implicitly establishing a new window start position WS.
> 
> (2) Respecting WS, redisplay puts window point at some position WP.
> 
> (3) A function on `pre-redisplay-function' decides that WP would end up
>      within intangible text and moves WP to a position WT.
> 
> (4) Redisplay notices that WT would end up in the scroll margin and
>      scrolls the window invalidating WS.  As a result windw text would
>      not scroll as intended by the user in (1).

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.

> But if redisplay were aware of intangible text, it would handle both -
> the intangible property and the scroll margin - in (2) and there would
> be no need to enter the (3)-(4) rigmarole.

Good luck implementing that!  We already have a thick forest of
conflicting goals in that area, due to requirements for scroll-margin,
scroll-*-aggressively, scroll-conservatively, and scroll-step.

> 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.  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.