On 03/16/2015 11:27 AM, Eli Zaretskii wrote: >> Date: Mon, 16 Mar 2015 11:18:58 -0700 >> From: Daniel Colascione >> CC: emacs-devel@gnu.org >> >> On 03/16/2015 11:05 AM, Eli Zaretskii wrote: >>>> From: Stefan Monnier >>>> Cc: dancol@dancol.org, emacs-devel@gnu.org >>>> 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?