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

[Artur Malabarba <bruce.connor.am@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]

On 24 Oct 2015 10:49 am, "Tassilo Horn" <tsdh@gnu.org> wrote:> >> 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).
>
> Yes, I think that would be a good idea.  Originally, `while-no-input'
> used (not (sit-for 0 0 t)) instead of (input-pending-p) which I think is
> pretty equivalent except that the former forces a redisplay.

Reading this discussion, it sounds to me like this is more about
post-command-hook than while-no-input.
By the time this code is run, the user's input has been received and
processed. The reason why redisplay doesn't happen is the fact that this
code is running on post-command-hook.

So maybe the docstring for post-command-hook should point out this detail
and recommend that functions added to this hook call sit-for if they're
going to do potentially expensive processing.

[-- Attachment #2: Type: text/html, Size: 1636 bytes --]