bug#19684: 25.0.50; `this-command` is set to `nil` before `window-scroll-functions` hook runs.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 24 Jan 2015 23:19:48 -0800
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> 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 needed 
> because the default value is `nil`.  In other words, something at the C source 
> 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
reset.

> 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.