[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.
signature.asc
Description: OpenPGP digital signature
- Re: Can we make set_point_both less expensive?, (continued)
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/15
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/16
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/16
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/16
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/16
- Re: Can we make set_point_both less expensive?, Daniel Colascione, 2015/03/16
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/16
- Re: Can we make set_point_both less expensive?, Daniel Colascione, 2015/03/16
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/16
- Re: Can we make set_point_both less expensive?,
Daniel Colascione <=
- Re: Can we make set_point_both less expensive?, Lennart Borgman, 2015/03/16
- Re: Can we make set_point_both less expensive?, Daniel Colascione, 2015/03/16
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/16
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/17
- RE: Can we make set_point_both less expensive?, Drew Adams, 2015/03/17
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/16
- Re: Can we make set_point_both less expensive?, martin rudalics, 2015/03/17
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/17
- Re: Can we make set_point_both less expensive?, martin rudalics, 2015/03/17
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/17