* bug#29518: 27.0.50; Compilation errors grab frame focus
@ 2017-12-01 0:29 Eric Abrahamsen
2018-01-06 14:50 ` Noam Postavsky
0 siblings, 1 reply; 10+ messages in thread
From: Eric Abrahamsen @ 2017-12-01 0:29 UTC (permalink / raw)
To: 29518
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29518: 27.0.50; Compilation errors grab frame focus
2017-12-01 0:29 bug#29518: 27.0.50; Compilation errors grab frame focus Eric Abrahamsen
@ 2018-01-06 14:50 ` Noam Postavsky
2018-01-06 20:13 ` Eric Abrahamsen
0 siblings, 1 reply; 10+ messages in thread
From: Noam Postavsky @ 2018-01-06 14:50 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 29518
[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]
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 #2: elisp triggering compile error --]
[-- Type: text/plain, Size: 256 bytes --]
;;; some-errors.el --- while ocmpiling
;; Copyright (C) 2008-2017 Free Software Foundation, Inc.
;; Version: 0.1
;; Package-Requires: ((cl-lib "0.5"))
(eval-when-compile
(sleep-for 1))
(eval-when-compile
(error "foo"))
;;; some-errors.el ends here
[-- Attachment #3: Type: text/plain, Size: 192 bytes --]
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29518: 27.0.50; Compilation errors grab frame focus
2018-01-06 14:50 ` Noam Postavsky
@ 2018-01-06 20:13 ` Eric Abrahamsen
2018-01-06 20:31 ` Noam Postavsky
0 siblings, 1 reply; 10+ messages in thread
From: Eric Abrahamsen @ 2018-01-06 20:13 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 29518
On 01/06/18 09:50 AM, Noam Postavsky wrote:
> 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.
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29518: 27.0.50; Compilation errors grab frame focus
2018-01-06 20:13 ` Eric Abrahamsen
@ 2018-01-06 20:31 ` Noam Postavsky
2018-01-15 4:40 ` Eric Abrahamsen
0 siblings, 1 reply; 10+ messages in thread
From: Noam Postavsky @ 2018-01-06 20:31 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 29518
Eric Abrahamsen <eric@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29518: 27.0.50; Compilation errors grab frame focus
2018-01-06 20:31 ` Noam Postavsky
@ 2018-01-15 4:40 ` Eric Abrahamsen
2018-01-15 12:07 ` Noam Postavsky
0 siblings, 1 reply; 10+ messages in thread
From: Eric Abrahamsen @ 2018-01-15 4:40 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 29518
On 01/06/18 15:31 PM, Noam Postavsky wrote:
> Eric Abrahamsen <eric@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29518: 27.0.50; Compilation errors grab frame focus
2018-01-15 4:40 ` Eric Abrahamsen
@ 2018-01-15 12:07 ` Noam Postavsky
2018-01-16 0:15 ` Eric Abrahamsen
0 siblings, 1 reply; 10+ messages in thread
From: Noam Postavsky @ 2018-01-15 12:07 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 29518
Eric Abrahamsen <eric@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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29518: 27.0.50; Compilation errors grab frame focus
2018-01-15 12:07 ` Noam Postavsky
@ 2018-01-16 0:15 ` Eric Abrahamsen
2022-01-23 15:51 ` Lars Ingebrigtsen
0 siblings, 1 reply; 10+ messages in thread
From: Eric Abrahamsen @ 2018-01-16 0:15 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 29518
On 01/15/18 07:07 AM, Noam Postavsky wrote:
> Eric Abrahamsen <eric@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29518: 27.0.50; Compilation errors grab frame focus
2018-01-16 0:15 ` Eric Abrahamsen
@ 2022-01-23 15:51 ` Lars Ingebrigtsen
2022-01-24 1:04 ` Eric Abrahamsen
0 siblings, 1 reply; 10+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-23 15:51 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 29518, Noam Postavsky
Eric Abrahamsen <eric@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29518: 27.0.50; Compilation errors grab frame focus
2022-01-23 15:51 ` Lars Ingebrigtsen
@ 2022-01-24 1:04 ` Eric Abrahamsen
2022-01-24 9:42 ` Lars Ingebrigtsen
0 siblings, 1 reply; 10+ messages in thread
From: Eric Abrahamsen @ 2022-01-24 1:04 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 29518, Noam Postavsky
On 01/23/22 16:51 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric@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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#29518: 27.0.50; Compilation errors grab frame focus
2022-01-24 1:04 ` Eric Abrahamsen
@ 2022-01-24 9:42 ` Lars Ingebrigtsen
0 siblings, 0 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-24 9:42 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 29518, Noam Postavsky
Eric Abrahamsen <eric@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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-01-24 9:42 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-01 0:29 bug#29518: 27.0.50; Compilation errors grab frame focus Eric Abrahamsen
2018-01-06 14:50 ` Noam Postavsky
2018-01-06 20:13 ` Eric Abrahamsen
2018-01-06 20:31 ` Noam Postavsky
2018-01-15 4:40 ` Eric Abrahamsen
2018-01-15 12:07 ` Noam Postavsky
2018-01-16 0:15 ` Eric Abrahamsen
2022-01-23 15:51 ` Lars Ingebrigtsen
2022-01-24 1:04 ` Eric Abrahamsen
2022-01-24 9:42 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).