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

[Aaron Jensen]

On Sun, Sep 26, 2021 at 1:51 PM martin rudalics <rudalics@gmx.at> wrote:
>
>  > I'll give the patch a shot. Does it filter events out for
>  > input-pending-p as well? From the thread, it seems like that is the
>  > idea, but I wanted to confirm that this particular patch intends to do
>  > that because vertico uses both while-no-input and input-pending-p.
>  >
>  > I don't know what else I have to offer on that thread over what is
>  > discussed. Is there a way for me to tell what is triggering
>  > input-pending-p to be t while I am in Emacs?
>
> Maybe
>
> (progn
>    (while (not (input-pending-p))
>      (sit-for 1))
>    (message "%s" last-input-event))
>
> can reveal something.  With emacs -Q do C-x 5 2 and put that form in
> *scratch*.  In the first frame show *Messages* so you don't miss any
> output.  Have a window from some other process ready that you can give
> focus to since otherwise you might get a `switch-frame-event' that
> intervenes - the "first" frame should _never_ get focus by the window
> manager.  Now eval the form in the second frame via C-x C-e and try to
> lower the second frame via the window manager and raise it again.  There
> should be no message.
>
> I cannot do that here because for some reason I don't see your problem.
> But I can reproduce it when dragging the second frame with the mouse.

I only see my problem sometimes. It doesn't reproduce if I restart
Emacs until it does (some random amount of time later)

When I do the above, if I focus away from the 2nd frame and back I see
nothing. If I minimize it (I'm on macOS, so not sure if that is the
closest thing to lowering) then I either get a focus-out-event or
switch-frame-event because it ends up giving the focus to the 1st
frame, that's just how macOS works. Maybe I can find a place to put
last-input-event if it reproduces again.

I'm using your patch now, so I can let you know if it happens again.

Thanks,

Aaron