bug#21747: 25.0.50; while-no-input breaks kbd event handling when called from post-command-hook

[Eli Zaretskii <eliz@gnu.org>]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Sat, 24 Oct 2015 09:42:36 +0200
> 
> With emacs -Q, evaluate the following in *stratch*:
> 
> --8<---------------cut here---------------start------------->8---
> (defun th/loop-on-no-input ()
>   (while-no-input (while t t)))
> 
> (add-hook 'post-command-hook #'th/loop-on-no-input)
> --8<---------------cut here---------------end--------------->8---
> 
> After having done that, the effect of pressing any key is deferred until
> you press the next key.  E.g., typing "foo" just inserts "fo", but after
> an additional C-b (the exact key doesn't matter) you'll see "foo".

I think what's deferred is redisplay, not the effect of pressing a
key.  IOW, the key does its thing, the character is inserted into the
current buffer, but redisplay doesn't run, and so you don't see that
inserted character, and think it was not inserted in the first place.

Given that, maybe I'm missing something, but what did you expect?  The
above literally says that Emacs shall loop indefinitely after
performing each command until there's more input.  And that's what you
get.  Right?

If I change the hook function to this:

 (defun th/loop-on-no-input ()
   (while-no-input (while t (sit-for 0))))

then the "delay" goes away (although I still don't recommend such
virulent post-command hooks, as they make an otherwise idle Emacs suck
all the juice out of a single execution unit).

Am I missing something here?