[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Monnier
Subject: Re: input-pending-p after make-frame-visible
Date: Mon, 27 Sep 2021 15:26:14 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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...).


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:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]