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

[Tassilo Horn <tsdh@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

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

Yes, you are right.

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

> 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

Indeed, that works.

> (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?

Obviously, `aggressive-indent-mode's `post-command-hook' is no infinite
loop but just a reasonably costly operation which should have the
ability to be aborted when the user keeps on typing:

  https://github.com/Malabarba/aggressive-indent-mode/blob/master/aggressive-indent.el#L357

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

Bye,
Tassilo