Re: input-pending-p after make-frame-visible

[Aaron Jensen]

On Sat, Oct 16, 2021 at 10:45 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Sat, Oct 16, 2021 at 10:16 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
> >
> > On Sat, Oct 16, 2021 at 3:54 AM martin rudalics <rudalics@gmx.at> wrote:
> > >
> > >  > It's already there, but it doesn't appear to be effective with either
> > >  > while-no-input or input-pending-p. Here's an updated repro:
> > >
> > > You could try to report the values of 'unread-command-events',
> > > 'unread-post-input-method-events' and 'unread-input-method-events' in
> > >
> > > (message "input-pending-p after: %S" (input-pending-p))
> >
> > I know 19 (help event) is pending from a patch I have to report what is 
> > pending:
>
> I wonder if the problem is just that `input-pending-p' does not
> respect `while-no-input-ignore-events'? `while-no-input' actually uses
> `input-pending-p' before it even attempts to run the body:
>
>           (setq val (or (input-pending-p)
>                  (progn ,@body)))
>
> I think that `readable_events' needs to be modified to do exactly what
> `kbd_buffer_store_buffered_event' does with regard to ignoring events
> if `READABLE_EVENTS_FILTER_EVENTS' is set.
>
> I have no idea why `USE_TOOLKIT_SCROLL_BARS' is considered when
> determining whether or not to require `READABLE_EVENTS_FILTER_EVENTS'
> when filtering out the focus events. I imagine that that focus event
> filtering could be replaced with a check against
> `while-no-input-ignore-events'
>
> Does that make sense?

Does the attached patch seem reasonable? It fixes the issue for me.
Please review for code style and commit message style, I'm still a
neophyte with that here.

0001-Ignore-events-in-input-pending-p.patch
Description: Binary data