[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can we make set_point_both less expensive?

From: Eli Zaretskii
Subject: Re: Can we make set_point_both less expensive?
Date: Mon, 16 Mar 2015 20:27:20 +0200

> Date: Mon, 16 Mar 2015 11:18:58 -0700
> From: Daniel Colascione <address@hidden>
> CC: address@hidden
> On 03/16/2015 11:05 AM, Eli Zaretskii wrote:
> >> From: Stefan Monnier <address@hidden>
> >> Cc: address@hidden, address@hidden
> >> Date: Mon, 16 Mar 2015 13:36:40 -0400
> >>
> >>>> what users of those features normally want is to catch movement of
> >>>> the cursor
> >>> You mean, we should do this in redisplay?
> >>
> >> Probably in pre-redisplay-hook or in pre/post-command-hook, yes.
> > 
> > That contradicts the "catch movement of cursor" idea: redisplay could
> > well move point from where it is found before redisplay, as you know.
> When does that matter? The intent is to get editing to behave _as if_
> invisible regions were intangible, and the existing invisible motion
> behavior seems mostly up to the task.

I wasn't talking about intangible, I was talking about the
point-entered and point-exited properties.

Stefan argues that these should actually be cursor-entered/exited,
i.e. we should run the hooks when we know that point has the value
that will be used to set the cursor there.  But doing that before
redisplay doesn't guarantee that, since redisplay sometimes moves
point to bring it into view.  So in that case, the hooks might run
when they shouldn't have, or vice versa.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]