bug#23002: 25.0.92; sluggish M-x

[Stefan Monnier <monnier@iro.umontreal.ca>]

> However, the sluggishness during the evaluation of
> execute-extended-command--shorter is common to the both ports on OS X,
> or non-interrupt-driven systems that use polling with SIGALRM for
> quit/while-no-input handling, in general.  I'm thinkng about applying
> the following patch to the Mac port, but it might also be useful for
> other systems.

Hmm... this seems to indicate that while-no-input is just not really
working in those systems.

> +      ;; On non-interrupt-driven systems, while-no-input polls for
> +      ;; input every `polling-period' (default 2) seconds, and that is
> +      ;; not frequent enough.  So we call input-pending-p manually.
> +      (if (and use-polling (input-pending-p))
> +          (signal 'quit nil))

Hmm... I'm not sure I understand: if input-pending-p returns non-nil,
why are we still in this loop?

IOW, I get the impression that the above call to input-pending-p will
end up triggering a kind of "poll" to fetch new input, so we should be
able to arrange for this fetching to trigger whatever should normally be
triggered by incoming input (e.g. getting out of the while-no-input
loop), so we could just reduce the above 2 lines to a single call to
`input-pending-p'.
I understand this may not seem like a big progress, but "every bit
counts" ;-) tho more seriously, I'm asking this mostly to better
understand what's going on (but also because I get the impression that
(signal 'quit nil) is not always the right thing to do).


        Stefan