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

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

bug#29518: 27.0.50; Compilation errors grab frame focus


From: Noam Postavsky
Subject: bug#29518: 27.0.50; Compilation errors grab frame focus
Date: Sat, 06 Jan 2018 09:50:31 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux)

tags 29518 + unreproducible
quit

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I've noticed over the past few weeks (couple of months?) that, while
> updating packages, any compilation errors result in the *Package List*
> frame grabbing focus.
>
> I start a package upgrade, switch to some other program, and then (some
> packages produce a lot of errors!) start a focus tug-of-war with the
> Emacs frame where the compilation is going on.
>
> I am on arch linux, with no DE, running i3 directly on X. I note that if
> I move to a different workspace, compilation errors cause the workspace
> where the frame lives to turn red (which seems to be the i3 behavior for
> frames with warnings or notifications or whatever the X terminology is),
> but I'm not yanked back there. If I'm in that workspace, however, the
> Emacs frame keeps jumping to the fore.
>
> I've looked through the Emacs git log to see if anything jumps out as
> having been changed, but most of the frame/focus stuff seems NS-related.
> But I'm pretty sure this is new behavior.
>
>
> In GNU Emacs 27.0.50 (build 13, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
>  of 2017-11-30 built on slip
> Repository revision: 3f3d98ee5851840228786390ee7dbf851d144eb8
> Windowing system distributor 'The X.Org Foundation', version 11.0.11905000

I can't reproduce this.  I'm also running i3 directly on X (Debian
stable though).  I tried M-x package-install-file RET some-errors.el RET
(see the attached file) then switch focus to a nearby terminal window.
The compile error did not trigger a change in focus.

Attachment: some-errors.el
Description: elisp triggering compile error

There have been some changes to the way timeouts are handles, which
could affect frame/focusing stuff (see #24091, #25521, and #29095), but
I don't think it should cause what you are seeing.

reply via email to

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