[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: Stefan Monnier
Subject: Re: Can we make set_point_both less expensive?
Date: Sat, 21 Mar 2015 09:59:35 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

>> > discussed.  Stefan wants redisplay to move point also in the case
>> > where some Lisp moved point and entered a region of buffer positions
>> > that has a certain text property.
>> Yes and no: I want pre-redisplay-function to do that.
> This will only work if pre-redisplay-function is called in a way that
> guarantees it will catch the position of point after the previous
> command.

I think I don't understand what you're saying:
pre-redisplay-function is called at the beginning of redisplay, so of
course it's called "after the previous command".

> Another, related, requirement is that we never call
> pre-redisplay-function when point is in a position that is not
> supposed to be visible by the user.

Again I don't understand.  pre-redisplay-function will be called at the
beginning of every redisplay, so it can't assume anything about where
point is.  On the contrary, it's pre-redisplay-function which would be
in charge of changing point (if needed) to take `cursor-intangible'
into account.

> Overall, it sounds like a non-trivial deviation from the original
> purpose of pre-redisplay-function, as I understand it.

I assure you it isn't: `cursor-intangible' was very much in my mind
while I was implementing this new feature.

> What I _am_ saying is that only redisplay, in its last part, knows
> where the cursor will be positioned.

Of course: pre-redisplay-function only has control of `point', not over
the cursor.  So it should move point away from the `cursor-intangible'
property.  The difference between point and the place where the cursor
is drawn on screen is not really relevant to `cursor-intangible'.


reply via email to

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