[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'.
Stefan
- Re: Can we make set_point_both less expensive?, (continued)
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/21
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/21
- Re: Can we make set_point_both less expensive?, martin rudalics, 2015/03/21
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/21
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/21
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/21
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/21
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/21
- Re: Can we make set_point_both less expensive?, martin rudalics, 2015/03/22
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/22
- Re: Can we make set_point_both less expensive?,
Stefan Monnier <=
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/21
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/21
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/21
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/21
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/21
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/21
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/22
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/22
- Re: Can we make set_point_both less expensive?, Stefan Monnier, 2015/03/22
- Re: Can we make set_point_both less expensive?, Eli Zaretskii, 2015/03/23