GNU bug report logs - #29518
27.0.50; Compilation errors grab frame focus

Previous Next

Package: emacs;

Reported by: Eric Abrahamsen <eric <at> ericabrahamsen.net>

Date: Fri, 1 Dec 2017 15:52:02 UTC

Severity: normal

Tags: moreinfo, unreproducible

Found in version 27.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29518 in the body.
You can then email your comments to 29518 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#29518; Package emacs. (Fri, 01 Dec 2017 15:52:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Eric Abrahamsen <eric <at> ericabrahamsen.net>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 01 Dec 2017 15:52:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Compilation errors grab frame focus
Date: Thu, 30 Nov 2017 16:29:56 -0800
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29518; Package emacs. (Sat, 06 Jan 2018 14:51:01 GMT) Full text and rfc822 format available.

Message #8 received at 29518 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 29518 <at> debbugs.gnu.org
Subject: Re: bug#29518: 27.0.50; Compilation errors grab frame focus
Date: Sat, 06 Jan 2018 09:50:31 -0500
[Message part 1 (text/plain, inline)]
tags 29518 + unreproducible
quit

Eric Abrahamsen <eric <at> 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.

[some-errors.el (text/plain, attachment)]
[Message part 3 (text/plain, inline)]
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.

Added tag(s) unreproducible. Request was from Noam Postavsky <npostavs <at> users.sourceforge.net> to control <at> debbugs.gnu.org. (Sat, 06 Jan 2018 14:51:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29518; Package emacs. (Sat, 06 Jan 2018 20:14:02 GMT) Full text and rfc822 format available.

Message #13 received at 29518 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 29518 <at> debbugs.gnu.org
Subject: Re: bug#29518: 27.0.50; Compilation errors grab frame focus
Date: Sat, 06 Jan 2018 12:13:44 -0800
On 01/06/18 09:50 AM, Noam Postavsky wrote:
> tags 29518 + unreproducible
> quit
>
> Eric Abrahamsen <eric <at> 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.

Thanks for the test! That triggers the same focus-grabbing behavior for
me -- from other Emacs frames, and other applications' frames, using
"emacs -Q".

You tried this also with switching to a different workspace? And it
didn't turn the workspace's tab red?

Perhaps something's configured differently on my system (though I don't
know why it would be, I didn't customize anything). Is there anything I
might be looking for in config.log?

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

I fooled with `x-wait-for-event-timeout' but that didn't do anything. I
suppose 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7 could be related
(FRAME_VISIBLE_P certainly sounds relevant) but I don't actually
understand what's happening in there. Should I try just reverting the
commit and re-building?

Thanks,
Eric




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29518; Package emacs. (Sat, 06 Jan 2018 20:32:02 GMT) Full text and rfc822 format available.

Message #16 received at 29518 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 29518 <at> debbugs.gnu.org
Subject: Re: bug#29518: 27.0.50; Compilation errors grab frame focus
Date: Sat, 06 Jan 2018 15:31:33 -0500
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Thanks for the test! That triggers the same focus-grabbing behavior for
> me -- from other Emacs frames, and other applications' frames, using
> "emacs -Q".
>
> You tried this also with switching to a different workspace? And it
> didn't turn the workspace's tab red?

I tried now switching to a different workspace after starting the
compile, the tab did not turn red.

> Perhaps something's configured differently on my system (though I don't
> know why it would be, I didn't customize anything). Is there anything I
> might be looking for in config.log?

I can't think of anything.  If you M-x debug-on-error RET x-focus-frame
RET do you get any hits?

>> 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.
>
> I fooled with `x-wait-for-event-timeout' but that didn't do anything. I
> suppose 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7 could be related
> (FRAME_VISIBLE_P certainly sounds relevant) but I don't actually
> understand what's happening in there. Should I try just reverting the
> commit and re-building?

I don't expect it to affect this, but since we have no other leads, I
suppose you may as well try it.  You would probably need to revert [1:
e1f6e3127a] first.

[1: e1f6e3127a]: 2017-09-29 18:40:06 -0400
  Bring back the busy wait after x_make_frame_visible (Bug#25521)
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e1f6e3127a292e6ba66d27c49ddda4fe949569f5




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29518; Package emacs. (Mon, 15 Jan 2018 04:41:01 GMT) Full text and rfc822 format available.

Message #19 received at 29518 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 29518 <at> debbugs.gnu.org
Subject: Re: bug#29518: 27.0.50; Compilation errors grab frame focus
Date: Sun, 14 Jan 2018 20:40:19 -0800
On 01/06/18 15:31 PM, Noam Postavsky wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Thanks for the test! That triggers the same focus-grabbing behavior for
>> me -- from other Emacs frames, and other applications' frames, using
>> "emacs -Q".
>>
>> You tried this also with switching to a different workspace? And it
>> didn't turn the workspace's tab red?
>
> I tried now switching to a different workspace after starting the
> compile, the tab did not turn red.
>
>> Perhaps something's configured differently on my system (though I don't
>> know why it would be, I didn't customize anything). Is there anything I
>> might be looking for in config.log?
>
> I can't think of anything.  If you M-x debug-on-error RET x-focus-frame
> RET do you get any hits?

Sorry about the slow response...

That was an odd recipe, but turning on debug-on-error, then running
several varieties of (x-focus-frame (window-frame)), including focusing
the current frame or other frames, never did anything other than what I
would expect it to -- returning nil when the frame was already focused,
and focusing the frame when it wasn't.

>>> 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.
>>
>> I fooled with `x-wait-for-event-timeout' but that didn't do anything. I
>> suppose 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7 could be related
>> (FRAME_VISIBLE_P certainly sounds relevant) but I don't actually
>> understand what's happening in there. Should I try just reverting the
>> commit and re-building?
>
> I don't expect it to affect this, but since we have no other leads, I
> suppose you may as well try it.  You would probably need to revert [1:
> e1f6e3127a] first.
>
> [1: e1f6e3127a]: 2017-09-29 18:40:06 -0400
>   Bring back the busy wait after x_make_frame_visible (Bug#25521)
>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e1f6e3127a292e6ba66d27c49ddda4fe949569f5

I wasn't able to revert those commits cleanly, and I guess I don't
really think that's the issue. I suspect this is a change in X behavior
(Arch has xorg-server 1.19), and maybe it's not worth chasing after at
this point. Maybe it's enough just to leave this report hanging here,
and see if anyone else runs into it?

Eric




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29518; Package emacs. (Mon, 15 Jan 2018 12:08:01 GMT) Full text and rfc822 format available.

Message #22 received at 29518 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 29518 <at> debbugs.gnu.org
Subject: Re: bug#29518: 27.0.50; Compilation errors grab frame focus
Date: Mon, 15 Jan 2018 07:07:09 -0500
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> On 01/06/18 15:31 PM, Noam Postavsky wrote:
>> I can't think of anything.  If you M-x debug-on-error RET x-focus-frame
>> RET do you get any hits?
>
> Sorry about the slow response...
>
> That was an odd recipe, but turning on debug-on-error, then running
> several varieties of (x-focus-frame (window-frame)), including focusing
> the current frame or other frames, never did anything other than what I
> would expect it to -- returning nil when the frame was already focused,
> and focusing the frame when it wasn't.

Oh, it's odd because I made a thinko, that should have been M-x
debug-on-entry ...
         ^^^^^

> I wasn't able to revert those commits cleanly, and I guess I don't
> really think that's the issue. I suspect this is a change in X behavior
> (Arch has xorg-server 1.19), and maybe it's not worth chasing after at
> this point. Maybe it's enough just to leave this report hanging here,
> and see if anyone else runs into it?

Hmm, I guess.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29518; Package emacs. (Tue, 16 Jan 2018 00:16:01 GMT) Full text and rfc822 format available.

Message #25 received at 29518 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 29518 <at> debbugs.gnu.org
Subject: Re: bug#29518: 27.0.50; Compilation errors grab frame focus
Date: Mon, 15 Jan 2018 16:15:19 -0800
On 01/15/18 07:07 AM, Noam Postavsky wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> On 01/06/18 15:31 PM, Noam Postavsky wrote:
>>> I can't think of anything.  If you M-x debug-on-error RET x-focus-frame
>>> RET do you get any hits?
>>
>> Sorry about the slow response...
>>
>> That was an odd recipe, but turning on debug-on-error, then running
>> several varieties of (x-focus-frame (window-frame)), including focusing
>> the current frame or other frames, never did anything other than what I
>> would expect it to -- returning nil when the frame was already focused,
>> and focusing the frame when it wasn't.
>
> Oh, it's odd because I made a thinko, that should have been M-x
> debug-on-entry ...
>          ^^^^^

Aha! Turning that on results in nothing happening -- re-running your
earlier recipe for compile/install errors still yanks focus, but does
not enter the debugger. Other frame-switching activity (eg
`helm-projectile-switch-to-buffer') does enter the debugger.

Weird.

Eric




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29518; Package emacs. (Sun, 23 Jan 2022 15:52:01 GMT) Full text and rfc822 format available.

Message #28 received at 29518 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 29518 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#29518: 27.0.50; Compilation errors grab frame focus
Date: Sun, 23 Jan 2022 16:51:07 +0100
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Aha! Turning that on results in nothing happening -- re-running your
> earlier recipe for compile/install errors still yanks focus, but does
> not enter the debugger. Other frame-switching activity (eg
> `helm-projectile-switch-to-buffer') does enter the debugger.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Are you still seeing this behaviour in recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 23 Jan 2022 15:52:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29518; Package emacs. (Mon, 24 Jan 2022 01:05:01 GMT) Full text and rfc822 format available.

Message #33 received at 29518 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 29518 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#29518: 27.0.50; Compilation errors grab frame focus
Date: Sun, 23 Jan 2022 17:04:28 -0800
On 01/23/22 16:51 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> Aha! Turning that on results in nothing happening -- re-running your
>> earlier recipe for compile/install errors still yanks focus, but does
>> not enter the debugger. Other frame-switching activity (eg
>> `helm-projectile-switch-to-buffer') does enter the debugger.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> Are you still seeing this behaviour in recent Emacs versions?

I'm not! Feel free to close.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#29518; Package emacs. (Mon, 24 Jan 2022 09:43:01 GMT) Full text and rfc822 format available.

Message #36 received at 29518 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 29518 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#29518: 27.0.50; Compilation errors grab frame focus
Date: Mon, 24 Jan 2022 10:42:39 +0100
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

>> Are you still seeing this behaviour in recent Emacs versions?
>
> I'm not! Feel free to close.

OK; done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 29518 <at> debbugs.gnu.org and Eric Abrahamsen <eric <at> ericabrahamsen.net> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 24 Jan 2022 09:43:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 21 Feb 2022 12:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 36 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.