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

[Stefan Monnier]

Aaron Jensen [2021-09-27 05:46:38] wrote:

> On Mon, Sep 27, 2021 at 4:51 AM martin rudalics <rudalics@gmx.at> wrote:
>>
>>  > I only see my problem sometimes. It doesn't reproduce if I restart
>>  > Emacs until it does (some random amount of time later)
>>
>> So you have to trigger it, somehow.
>
> Right, and I have no idea how at the moment.
>
>>  > When I do the above, if I focus away from the 2nd frame and back I see
>>  > nothing.
>>
>> With and/or without my patch?  Please compare the behaviors.
>
> Same w/o the patch, I don't know if application focus events are not
> handled on macos, only window (frame) focus changes
>
>>  > 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.
>>
>> That's why I told you to provide for a third window (using another Emacs
>> process or another application) that gets focus when you minimize the
>> Emacs frame.  But getting a focus-out event with the patch applied _is_
>> bad - these should be caught by the patch.
>
> Right, there is a 3rd window, but that's not how macOS works. I think
> I found how to do it though. If I minimize the messages frame, then
> eval the form, then minimize frame that and raise it, I do get a
> focus-out on that frame, with or without the patch.
>
>>  > 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.
>>
>> You can also set 'while-no-input-ignore-events' to include or rule out
>> specific events.
>
> Ok, I'll see if I can do that once I get it reproducing again.
>
> Thanks,
>
> Aaron

FWIW, last time I had a similar problem I cooked up the following patch
in the hope of catching the offending event in `throw-on-input--trace`.

It's not in an acceptable form to be installed into `master`, but maybe
someone can be inspired to clean it up (and avoid the implicit memory
leak, etc...).


        Stefan


diff --git a/src/keyboard.c b/src/keyboard.c
index bc6f97586dd..4e1a1f51ef5 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -3682,7 +3730,11 @@ kbd_buffer_store_buffered_event (union 
buffered_input_event *event,
      as input, set quit-flag to cause an interrupt.  */
   if (!NILP (Vthrow_on_input)
       && NILP (Fmemq (ignore_event, Vwhile_no_input_ignore_events)))
-    Vquit_flag = Vthrow_on_input;
+    {
+      Vquit_flag = Vthrow_on_input;
+      Vthrow_on_input__trace = Fcons (make_lispy_event (&event->ie),
+                                      Vthrow_on_input__trace);
+    }
 }
 
 
@@ -12412,6 +12387,10 @@ syms_of_keyboard (void)
 peculiar kind of quitting.  */);
   Vthrow_on_input = Qnil;
 
+  DEFVAR_LISP ("throw-on-input--trace", Vthrow_on_input__trace,
+               doc: /* Trace of events that caused a `throw-on-input`. */);
+  Vthrow_on_input__trace = Qnil;
+
   DEFVAR_LISP ("command-error-function", Vcommand_error_function,
               doc: /* Function to output error messages.
 Called with three arguments: