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
Reported by: emacser <laszlomail <at> protonmail.com>
Date: Wed, 13 Jan 2021 17:09:02 UTC
Severity: normal
Tags: wontfix
Found in version 27.1
Done: Stefan Kangas <stefan <at> marxist.se>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> (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
This bug report was last modified 4 years and 33 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.