GNU bug report logs - #45844
27.1; unwanted raising of other frame when emacs is in the backgound and switch-to-buffer is used in a dedicated frame

Previous Next

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

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

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

From: emacser <laszlomail <at> protonmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 27.1;
 unwanted raising of other frame when emacs is in the backgound and
 switch-to-buffer is used in a dedicated frame
Date: Wed, 13 Jan 2021 17:08:15 +0000

[Message part 1 (text/plain, inline)]

If I have a separate info frame beside my main emacs frame and the info frame is

(set-frame-parameter nil 'unsplittable t)
(set-window-dedicated-p nil t)

and I switch to this info frame, eval the below code (M-:) and
switch to an other app then my main emacs frame is raised
automatically to the foreground when the timer runs.

switch-to-buffer should not cause emacs bringing a frame to the
foreground (and thereby interrupting the user) without the user
asking for this behavior.

GNU Emacs 27.1 (build 1, x86_64-w64-mingw32) of 2020-08-12

(run-with-timer
3 nil
(lambda ()
(with-current-buffer "*test*"
(erase-buffer))

(set-process-sentinel
(start-process-shell-command
"test" "*test*" "dir d:")

(lambda (process event)
(switch-to-buffer "*test*")
(goto-char (point-min))
))))

[Message part 2 (text/html, inline)]

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

From: emacser <laszlomail <at> protonmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: Re: 27.1;
 unwanted raising of other frame when emacs is in the backgound and
 switch-to-buffer is used in a dedicated frame
Date: Wed, 13 Jan 2021 17:17:54 +0000

[Message part 1 (text/plain, inline)]

You don't even need the process, it's just a leftover from a test case.
The bug also occurs if only switch-to-buffer is called, but this code
must be run from the dedicated frame to get the unwanted raising
effect of the other frame:

(run-with-timer
3 nil
(lambda ()
(switch-to-buffer "*test*")))

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: emacser <laszlomail <at> protonmail.com>, 45844 <at> debbugs.gnu.org
Subject: Re: bug#45844: 27.1; unwanted raising of other frame when emacs is in
 the backgound and switch-to-buffer is used in a dedicated frame
Date: Wed, 13 Jan 2021 19:07:59 +0100

> (run-with-timer
> 3 nil
> (lambda ()
> (switch-to-buffer "*test*")))

You are asking for the impossible.  'switch-to-buffer' with a dedicated
window on an unsplittable frame will inevitably trigger 'pop-to-buffer'
as documented in the Elisp manual:

     Sometimes, the selected window may not be suitable for displaying
     the buffer.  This happens if the selected window is a minibuffer
     window, or if the selected window is strongly dedicated to its
     buffer (*note Dedicated Windows::).  In such cases, the command
     normally tries to display the buffer in some other window, by
     invoking ‘pop-to-buffer’ (see below).

And 'pop-to-buffer' makes a new frame because it cannot use the selected
one, raises that frame and even requests input focus for it.

I haven't much to recommend for how to handle such situations.  You can
try the following:

- Make an invisible frame when you start running the timer, maybe giving
  it a non-nil ‘no-focus-on-map’ parameter.

- Use 'display-buffer' to show *test* in that frame and make that frame
  visible, preferably using an 'inhibit-switch-frame' alist entry.

In either case it will be up to your WM whether it will raise that frame
and give it focus.  Often it does both, "stealing" another application's
focus.

martin

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

From: emacser <laszlomail <at> protonmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: "45844 <at> debbugs.gnu.org" <45844 <at> debbugs.gnu.org>
Subject: Re: bug#45844: 27.1;
 unwanted raising of other frame when emacs is in the backgound and
 switch-to-buffer is used in a dedicated frame
Date: Wed, 13 Jan 2021 18:49:13 +0000

>
> And 'pop-to-buffer' makes a new frame because it cannot use the selected
> one, raises that frame and even requests input focus for it.

There is no need to create a new frame, since the other frame exists in my case,
but if pop-to-buffer raises that automatically then it's understandable why
it comes to the foreground.

A possible solution for this can be checking if pop-to-buffer is called interactively
by the user. If so then it calls select-frame-set-input-focus like now, if not
then it calls select-frame instead.

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

From: martin rudalics <rudalics <at> gmx.at>
To: emacser <laszlomail <at> protonmail.com>
Cc: "45844 <at> debbugs.gnu.org" <45844 <at> debbugs.gnu.org>
Subject: Re: bug#45844: 27.1; unwanted raising of other frame when emacs is in
 the backgound and switch-to-buffer is used in a dedicated frame
Date: Thu, 14 Jan 2021 08:40:23 +0100

>> And 'pop-to-buffer' makes a new frame because it cannot use the selected
>> one, raises that frame and even requests input focus for it.
>
> There is no need to create a new frame, since the other frame exists in my case,
> but if pop-to-buffer raises that automatically then it's understandable why
> it comes to the foreground.
>
> A possible solution for this can be checking if pop-to-buffer is called interactively
> by the user. If so then it calls select-frame-set-input-focus like now, if not
> then it calls select-frame instead.

Sorry but we can't do that.  `switch-to-buffer' has to provide the
window the next keystroke will be addressed to.  That is carved in
stone.

I still don't understand why you insist on using `switch-to-buffer'
here.  Why don't you just call `display-buffer' if you don't want to
edit that buffer anyway?

martin

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

From: emacser <laszlomail <at> protonmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: "45844 <at> debbugs.gnu.org" <45844 <at> debbugs.gnu.org>
Subject: Re: bug#45844: 27.1;
 unwanted raising of other frame when emacs is in the backgound and
 switch-to-buffer is used in a dedicated frame
Date: Thu, 14 Jan 2021 08:20:55 +0000

On Thursday, January 14, 2021 8:40 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>
> Sorry but we can't do that.`switch-to-buffer' has to provide the window the next keystroke will be addressed to. That is carved in stone. I still don't understand why you insist on using`switch-to-buffer'
> here. Why don't you just call `display-buffer' if you don't want to
> edit that buffer anyway?
>

I'll try that, I only found it strange that if a background timer uses
switch-to-buffer and the frame is in in the background then why the frame
is raised. If it's not triggered by a user interaction then there is
no practical reason to bring the frame into the foreground, because the
user is using an other app, so he doesn't want to type into that frame
at that point. The frame should only switch to the buffer and remain in the
background, so when the user get backs to emacs then he can see the result
of the background process presented to him.

It sounds like a bug to me, but I accept if you say it's hard to implement
for some reason and I'll change my code to use an other method.

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

From: martin rudalics <rudalics <at> gmx.at>
To: emacser <laszlomail <at> protonmail.com>
Cc: "45844 <at> debbugs.gnu.org" <45844 <at> debbugs.gnu.org>
Subject: Re: bug#45844: 27.1; unwanted raising of other frame when emacs is in
 the backgound and switch-to-buffer is used in a dedicated frame
Date: Thu, 14 Jan 2021 10:26:01 +0100

> I'll try that, I only found it strange that if a background timer uses
> switch-to-buffer

Timers should never use `switch-to-buffer'.  If they want to draw
attention to the object they want to display, they should use
`pop-to-buffer'.  Otherwise, `display-buffer' is the function to be
preferred although if that needs a new frame, it will raise that frame
too unless your WM prevents it.

'switch-to-buffer' is a user command and should not be called by any
Lisp code.  Unfortunately, it's done a hundred times in the Emacs code
base and there's nothing we can reasonably do about that.

> and the frame is in in the background then why the frame
> is raised. If it's not triggered by a user interaction then there is
> no practical reason to bring the frame into the foreground, because the
> user is using an other app, so he doesn't want to type into that frame
> at that point. The frame should only switch to the buffer and remain in the
> background, so when the user get backs to emacs then he can see the result
> of the background process presented to him.
>
> It sounds like a bug to me, but I accept if you say it's hard to implement
> for some reason and I'll change my code to use an other method.

It's by no means hard to implement (preventing a new frame from getting
raised is much harder).  But we cannot change the semantics of
`switch-to-buffer' in this regard.  As long as window managers permit us
to do that, it will raise the frame it uses and give it focus.

martin

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

From: emacser <laszlomail <at> protonmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: "45844 <at> debbugs.gnu.org" <45844 <at> debbugs.gnu.org>
Subject: Re: bug#45844: 27.1;
 unwanted raising of other frame when emacs is in the backgound and
 switch-to-buffer is used in a dedicated frame
Date: Thu, 14 Jan 2021 09:39:56 +0000

>
> It's by no means hard to implement (preventing a new frame from getting
> raised is much harder). But we cannot change the semantics of
> `switch-to-buffer' in this regard. As long as window managers permit us
> to do that, it will raise the frame it uses and give it focus.
>

OK, the bug can be closed then if it's wontfix.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: emacser <laszlomail <at> protonmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>,
 "45844 <at> debbugs.gnu.org" <45844 <at> debbugs.gnu.org>
Subject: Re: bug#45844: 27.1; unwanted raising of other frame when emacs is in
 the backgound and switch-to-buffer is used in a dedicated frame
Date: Tue, 20 Apr 2021 22:35:37 -0500

tags 45844 wontfix
close 45844
thanks

emacser <laszlomail <at> protonmail.com> writes:

>> It's by no means hard to implement (preventing a new frame from getting
>> raised is much harder). But we cannot change the semantics of
>> `switch-to-buffer' in this regard. As long as window managers permit us
>> to do that, it will raise the frame it uses and give it focus.
>>
>
> OK, the bug can be closed then if it's wontfix.

Done.

Previous Next

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