Re: Can we make set_point_both less expensive?

[Daniel Colascione]

On 03/16/2015 11:27 AM, Eli Zaretskii wrote:
>> 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.

Sure, but intangible is the most useful facility we're talking about
disabling by default. Aren't point-entered and point-exited even less
useful? Looking through the source, ERC uses these hooks to echo
timestamps, which it could do just as well with a post-command-hook.
Gnus does something similar to update its toolbar. table also uses these
hooks to refresh its menu bar.

Are there any other important use cases?

signature.asc
Description: OpenPGP digital signature