[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19684: 25.0.50; `this-command` is set to `nil` before `window-scroll
bug#19684: 25.0.50; `this-command` is set to `nil` before `window-scroll-functions` hook runs.
Sun, 25 Jan 2015 17:33:20 +0200
> Date: Sat, 24 Jan 2015 23:19:48 -0800
> From: Keith David Bershatsky <address@hidden>
> To the extent that a user wishes to use the value of `this-command` within a
> function attached to the `window-scroll-functions` hook, a workaround is
> because the default value is `nil`. In other words, something at the C
> code level is setting the value to `nil` before the `window-scroll-functions`
> hook runs.
That "something" is the command loop itself: it resets 'this-command'
when the command finishes and returns to the loop.
Recall that in Emacs, execution of commands running the Lisp
interpreter is separated from redisplay: the latter runs when Emacs is
idle and is waiting for input. Since most of the calls to
window-scroll-functions are made by the display engine, the command
already returned to the command loop by that time.
> Calling `redisplay` somehow prevents `this-command` from being reset
> to `nil`
I hope it is now clear why this happens: in this scenario redisplay is
entered before the command finishes, so 'this-command' was still not
> The most reliable test I have discovered to pinpoint when the
> `window-scroll-functions` hook will activate is by having the following code
> within a function attached to the `post-command-hook`:
> (pos-visible-in-window-p (point) (get-buffer-window (current-buffer)
> (selected-frame))). If the result is `t`, then the `window-scroll-functions`
> hook will be activating.
You are well-advised not to depend on such implementation details.
> Although this bug report has been submitted with Emacs Trunk from October 1,
> 2014; the behavior is the same with Emacs Trunk built on January 1, 2015.
Emacs always behaved like that. And it's not a bug.