[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: Daniel Colascione
Subject: Re: Can we make set_point_both less expensive?
Date: Mon, 16 Mar 2015 13:43:57 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 03/16/2015 12:42 PM, Eli Zaretskii wrote:
>> Date: Mon, 16 Mar 2015 11:31:57 -0700
>> From: Daniel Colascione <address@hidden>
>> CC: address@hidden, address@hidden
>>> 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.
> My understanding was that Stefan wants these hooks replaced with
> different ones, not throw them away.  So I was talking about those
> different hooks.

I don't see a good use case for either the old or the new hook. Instead
of making point motion updates "edge triggered" (i.e., run a function
when point enters or exits a certain region), modes should be using a
"level triggered" approach, where they inspect the current location of
point and update whatever state they need based on that current location.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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