bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#17439: 24.3.50; run-with-idle-timer runs on focus-out


From: Stefan Monnier
Subject: bug#17439: 24.3.50; run-with-idle-timer runs on focus-out
Date: Sun, 11 May 2014 18:29:19 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

>> Huh?  `run-with-idle-timer' is not supposed to generate any event.
> It runs on `focus-out',

It does.  But that doesn't mean that "`run-with-idle-timer' generates
the `focus-out'".  The `focus-out' event is generated by the
window-manager plus Emacs's C code in response to some situation such as
a user action.  And after execution of the command bound to `focus-out',
we run the idle timers.

> (defun test () (message "%S" last-input-event))
> (setq timer (run-with-idle-timer 0.1 t 'test))
> It generates:
> (focus-in #<frame address@hidden 0x1121908>)
> (focus-out #<frame address@hidden 0x1121908>)

Your code generates some output which mentions `focus-out' but it did
not generate those events.

>>> +                    ;; Some window managers generate the `focus-in' event
>>> +                    ;; when showing the Window List,
>> What means "showing the Window List"?
> It depends on the desktop environment, but usually this is a list of windows
> shown after typing Alt-Tab.

Then I still don't understand: why would Emacs get a focus-in event when
the window-manager shows the "Window List"?  I'd maybe expect
a focus-*out* event, since suddenly the focus might go from Emacs to the
Window List.

Or do you mean that Emacs gets a focus-in event when the user selects
an Emacs frame in the window manager's Window List (maybe even if that
selection is transient while looping through all windows)?

>>> +                    ;;  but `raise-frame' forcibly switches to an Emacs
>>> frame when the Window List is active,

Well, this behavior is a choice of the window-manager.  While I'm very
happy to call raise-frame less often (so I generally agree with the
direction of the patch), you could argue that this might be a bug in the
window-manager.

> This is specific behavior observed at least in one window manager (Gnome 2),
> where typing Alt-Tab shows the Window List and generates the `focus-in' event
> in Emacs at the same time.

OK, I think I understand.  Please make the comment a bit more clear
about the fact that the focus-in event might come even *while* (rather
than *when*) the "Window List thingy to select a window" is active.

> But maybe it should be handled like `focus-in', i.e. also
> to not ignore it in `mouse-avoidance-ignore-p' and to move
> the mouse pointer after switching between Emacs frames.

I don't have a strong opinion either way, but it seems like they
generally should be handled in the same way, since they occur in similar
circumstances (one being when you focus-in from another frame of the
same Emacs session, while the other is when you focus-in from some
other process).


        Stefan





reply via email to

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