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

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 21747@debbugs.gnu.org
> Date: Sat, 24 Oct 2015 10:53:12 +0200
> 
> > 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?
> 
> Correct, but when the input eventually arrives, I expect to see its
> effects as if it had arrived outside of the `while-no-input'.

That effect was not yet produced, because the arriving input was not
yet consumed by the time while-no-input returns, that input is still
"pending".  For it to be consumed and acted upon, you need another
crank of the Emacs main loop and another redisplay cycle (which is
again delayed by the while-no-input loop).  So the one-character delay
goes on forever.

> So the question is: should `while-no-input' call (sit-for 0) as the
> first statement in the `progn' or should functions using
> `while-no-input' do that on their own?  I'd prefer the former because
> the current behavior is not really obvious (at least not to me nor
> Artur).

I don't have enough experience in using while-no-input to answer that.
Perhaps others could chime in and voice their opinions.  Maybe we
should have a discussion on emacs-devel about this (because many
people who read emacs-devel don't read the bug list).