GNU bug report logs - #78527
30.1; Mishaving new frame creation in MacOS on new desktop

Previous Next

To reply to this bug, email your comments to 78527 AT debbugs.gnu.org.

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

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

From: Boris Aronov <aronov.boris <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; Mishaving new frame creation in MacOS on new desktop
Date: Tue, 20 May 2025 21:35:04 +0200

This is on MacOS in GUI mode.

Recipe: Make emacs full screen by clicking on the green button (maybe
also <f11>?).  Now in this frame make another one (for example, by
cmd-N or C-x 5 2).

A new frame opens on a new desktop.  Focus shifts there.  Now try to
execute a command by esc-x (M-x).  There is no prompt on the bottom of
the screen.  If you shift to the previous desktop, you will see that the
prompt for the command to be executed appears there.  [I am not 100%
sure, but I also think the wrong emacs window is selected, as whatever
characters typed after M-x end up in the wrong place.]

I believe the mis-behavior also happens with some other actions
immediately after new frame creation, but have not been able to figure
out precisely when.

Notice that the trouble does not appear if I have a non-full-screen
Emace and make a new frame.

Emacs downloaded from MacPorts.  Versions before 30.1 did not have
this "feature."

Thanks in advance.

–BA

In GNU Emacs 30.1 (build 2, x86_64-apple-darwin21.6.0, NS appkit-2113.65
 Version 12.7.6 (Build 21H1320)) of 2025-02-26 built on
 montereyx.internal.macports.net
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.7.6

Configured using:
 'configure --prefix=/opt/local --disable-silent-rules --without-dbus
 --without-gconf --without-libotf --without-m17n-flt --with-libgmp
 --with-gnutls --with-xml2 --with-modules --with-sqlite3 --with-webp
 --with-native-compilation=aot --infodir /opt/local/share/info/emacs
 --disable-gc-mark-trace --with-ns --with-lcms2 --without-harfbuzz
 --without-imagemagick --without-xaw3d --with-rsvg --with-tree-sitter
 'CFLAGS=-pipe -Os -Wno-attributes
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch
 x86_64' 'CPPFLAGS=-I/opt/local/include
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk'
 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-no_pie
 -Wl,-rpath /opt/local/lib/gcc14 -Wl,-rpath /opt/local/lib
 -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
 -arch x86_64''

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY
KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XIM ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  isearch-fold-quotes-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort emacsbug info help-mode mail-extr compile comp-run
comp-common org-timer org-colview org-clock org-attach org-archive
org-agenda org-element org-persist org-id org-element-ast inline
avl-tree generator org-refile ol-eww eww xdg url-queue mm-url ol-rmail
ol-mhe ol-irc ol-info ol-gnus nnselect gnus-art mm-uu mml2015 mm-view
mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg
dom gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap
nnmail browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util url-parse
auth-source cl-seq eieio eieio-core cl-macs json map byte-opt gv
bytecomp byte-compile url-vars mail-source utf7 nnoo parse-time
gnus-spec gnus-int gnus-range message sendmail mailcap yank-media puny
rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus nnheader
gnus-util text-property-search mail-utils range mm-util mail-prsvr
wid-edit ol-docview doc-view filenotify jka-compr image-mode exif dired
dired-loaddefs ol-bibtex bibtex iso8601 ol-bbdb ol-w3m ol-doi
org-link-doi reporter org ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-macro org-src sh-script smie treesit executable ob-comint
org-pcomplete pcomplete comint ansi-osc ansi-color ring org-list
org-footnote org-faces org-entities time-date subr-x noutline outline
icons ob-emacs-lisp ob-core ob-eval org-version org-cycle org-table ol
rx org-fold org-fold-core org-keys oc org-loaddefs thingatpt find-func
cal-menu calendar cal-loaddefs org-compat org-macs format-spec
cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 299721 44845) (symbols 48 22479 0) (strings 32 81187 9240)
 (string-bytes 1 2469307) (vectors 16 37357)
 (vector-slots 8 468691 25511) (floats 8 356 198)
 (intervals 56 4527 0) (buffers 992 14))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Boris Aronov <aronov.boris <at> gmail.com>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 martin rudalics <rudalics <at> gmx.at>
Cc: 78527 <at> debbugs.gnu.org
Subject: Re: bug#78527: 30.1;
 Mishaving new frame creation in MacOS on new desktop
Date: Thu, 22 May 2025 13:01:49 +0300

> From: Boris Aronov <aronov.boris <at> gmail.com>
> Date: Tue, 20 May 2025 21:35:04 +0200
> 
> This is on MacOS in GUI mode.
> 
> Recipe: Make emacs full screen by clicking on the green button (maybe
> also <f11>?).  Now in this frame make another one (for example, by
> cmd-N or C-x 5 2).
> 
> A new frame opens on a new desktop.  Focus shifts there.  Now try to
> execute a command by esc-x (M-x).  There is no prompt on the bottom of
> the screen.  If you shift to the previous desktop, you will see that the
> prompt for the command to be executed appears there.  [I am not 100%
> sure, but I also think the wrong emacs window is selected, as whatever
> characters typed after M-x end up in the wrong place.]
> 
> I believe the mis-behavior also happens with some other actions
> immediately after new frame creation, but have not been able to figure
> out precisely when.
> 
> Notice that the trouble does not appear if I have a non-full-screen
> Emace and make a new frame.
> 
> Emacs downloaded from MacPorts.  Versions before 30.1 did not have
> this "feature."

Gerd and Martin, any suggestions or comments?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 78527 <at> debbugs.gnu.org,
 Boris Aronov <aronov.boris <at> gmail.com>
Subject: Re: bug#78527: 30.1; Mishaving new frame creation in MacOS on new
 desktop
Date: Thu, 22 May 2025 12:25:58 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Boris Aronov <aronov.boris <at> gmail.com>
>> Date: Tue, 20 May 2025 21:35:04 +0200
>> 
>> This is on MacOS in GUI mode.
>> 
>> Recipe: Make emacs full screen by clicking on the green button (maybe
>> also <f11>?).  Now in this frame make another one (for example, by
>> cmd-N or C-x 5 2).
>> 
>> A new frame opens on a new desktop.  Focus shifts there.  Now try to
>> execute a command by esc-x (M-x).  There is no prompt on the bottom of
>> the screen.  If you shift to the previous desktop, you will see that the
>> prompt for the command to be executed appears there.  [I am not 100%
>> sure, but I also think the wrong emacs window is selected, as whatever
>> characters typed after M-x end up in the wrong place.]
>> 
>> I believe the mis-behavior also happens with some other actions
>> immediately after new frame creation, but have not been able to figure
>> out precisely when.
>> 
>> Notice that the trouble does not appear if I have a non-full-screen
>> Emace and make a new frame.
>> 
>> Emacs downloaded from MacPorts.  Versions before 30.1 did not have
>> this "feature."
>
> Gerd and Martin, any suggestions or comments?

Doesn't seem to happen with -Q for me, neither on master not emacs-30 (a
version of emacs-30 that is ca 180 commits behind; savannah seems to be
down again. This is macOS 15.5 on an M1 mac.

C-x 5 2 does not open a new frame on a new desktop for me. The new frame
opens on top of the fullsize first frame.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: rudalics <at> gmx.at, 78527 <at> debbugs.gnu.org, aronov.boris <at> gmail.com
Subject: Re: bug#78527: 30.1; Mishaving new frame creation in MacOS on new
 desktop
Date: Thu, 22 May 2025 15:07:31 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Boris Aronov <aronov.boris <at> gmail.com>,  martin rudalics
>  <rudalics <at> gmx.at>,  78527 <at> debbugs.gnu.org
> Date: Thu, 22 May 2025 12:25:58 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Boris Aronov <aronov.boris <at> gmail.com>
> >> Date: Tue, 20 May 2025 21:35:04 +0200
> >> 
> >> This is on MacOS in GUI mode.
> >> 
> >> Recipe: Make emacs full screen by clicking on the green button (maybe
> >> also <f11>?).  Now in this frame make another one (for example, by
> >> cmd-N or C-x 5 2).
> >> 
> >> A new frame opens on a new desktop.  Focus shifts there.  Now try to
> >> execute a command by esc-x (M-x).  There is no prompt on the bottom of
> >> the screen.  If you shift to the previous desktop, you will see that the
> >> prompt for the command to be executed appears there.  [I am not 100%
> >> sure, but I also think the wrong emacs window is selected, as whatever
> >> characters typed after M-x end up in the wrong place.]
> >> 
> >> I believe the mis-behavior also happens with some other actions
> >> immediately after new frame creation, but have not been able to figure
> >> out precisely when.
> >> 
> >> Notice that the trouble does not appear if I have a non-full-screen
> >> Emace and make a new frame.
> >> 
> >> Emacs downloaded from MacPorts.  Versions before 30.1 did not have
> >> this "feature."
> >
> > Gerd and Martin, any suggestions or comments?
> 
> Doesn't seem to happen with -Q for me, neither on master not emacs-30 (a
> version of emacs-30 that is ca 180 commits behind; savannah seems to be
> down again. This is macOS 15.5 on an M1 mac.

So this could be MacPorts specific, then.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Boris Aronov <aronov.boris <at> gmail.com>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 78527 <at> debbugs.gnu.org
Subject: Re: bug#78527: 30.1; Mishaving new frame creation in MacOS on new
 desktop
Date: Thu, 22 May 2025 16:44:18 +0200

> Gerd and Martin, any suggestions or comments?

I'd like to understand the focus issue.  What does C-x 5 o do when run
in the old frame?  What does running 'foo' defined as

(defun foo ()
  (interactive)
  (let ((frame (make-frame)))
    (sit-for 3)
    (message "%s" (frame-focus-state frame))))

report?  Is the message shown in both frames?

Does 'foo' specified as

(defun foo ()
  (interactive)
  (let ((frame (make-frame)))
    (select-frame-set-input-focus frame)))

behave the same way?  Does

(add-hook 'after-make-frame-functions 'select-frame-set-input-focus)

change anything?  Does

(add-hook 'after-make-frame-functions 'redirect-frame-focus)

change anything?

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: aronov.boris <at> gmail.com, gerd.moellmann <at> gmail.com
Cc: martin rudalics <rudalics <at> gmx.at>, 78527 <at> debbugs.gnu.org
Subject: Re: bug#78527: 30.1; Mishaving new frame creation in MacOS on new
 desktop
Date: Sat, 31 May 2025 14:19:40 +0300

Ping!  Boris and Gerd, could you please answer martin's questions?

> Date: Thu, 22 May 2025 16:44:18 +0200
> Cc: 78527 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > Gerd and Martin, any suggestions or comments?
> 
> I'd like to understand the focus issue.  What does C-x 5 o do when run
> in the old frame?  What does running 'foo' defined as
> 
> (defun foo ()
>    (interactive)
>    (let ((frame (make-frame)))
>      (sit-for 3)
>      (message "%s" (frame-focus-state frame))))
> 
> report?  Is the message shown in both frames?
> 
> Does 'foo' specified as
> 
> (defun foo ()
>    (interactive)
>    (let ((frame (make-frame)))
>      (select-frame-set-input-focus frame)))
> 
> behave the same way?  Does
> 
> (add-hook 'after-make-frame-functions 'select-frame-set-input-focus)
> 
> change anything?  Does
> 
> (add-hook 'after-make-frame-functions 'redirect-frame-focus)
> 
> change anything?
> 
> martin
> 

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 78527 <at> debbugs.gnu.org,
 aronov.boris <at> gmail.com
Subject: Re: bug#78527: 30.1; Mishaving new frame creation in MacOS on new
 desktop
Date: Sat, 31 May 2025 20:48:34 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Ping!  Boris and Gerd, could you please answer martin's questions?

I think the question was for Boris.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 78527 <at> debbugs.gnu.org, aronov.boris <at> gmail.com
Subject: Re: bug#78527: 30.1; Mishaving new frame creation in MacOS on new
 desktop
Date: Sun, 1 Jun 2025 08:43:56 +0200

> I think the question was for Boris.

Indeed.

martin

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

From: Boris Aronov <aronov.boris <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 78527 <at> debbugs.gnu.org
Subject: Re: bug#78527: 30.1;
 Mishaving new frame creation in MacOS on new desktop
Date: Tue, 3 Jun 2025 21:43:45 +0200

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

Sorry.  Will reply shortly.  Real life interfered.

–BA

On Sun, Jun 1, 2025 at 8:44 AM martin rudalics <rudalics <at> gmx.at> wrote:

> > I think the question was for Boris.
>
> Indeed.
>
> martin
>
>

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

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

From: Boris Aronov <aronov.boris <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 78527 <at> debbugs.gnu.org
Subject: Re: bug#78527: 30.1;
 Mishaving new frame creation in MacOS on new desktop
Date: Wed, 4 Jun 2025 05:52:46 +0200

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

Hi,

On Thu, May 22, 2025 at 4:44 PM martin rudalics <rudalics <at> gmx.at> wrote:

>  > Gerd and Martin, any suggestions or comments?
>
> I'd like to understand the focus issue.  What does C-x 5 o do when run
> in the old frame?


- Opened "Emacs -Q"
- Clicked the green button (fullscreen)
- C-x 5 2 (new frame opens on another desktop)
- I swipe to original desktop
- C-x 5 o switches to the new one and repeating it takes me back

What does running 'foo' defined as
>
> (defun foo ()
>    (interactive)
>    (let ((frame (make-frame)))
>      (sit-for 3)
>      (message "%s" (frame-focus-state frame))))
>

When I do this in an non-full-screen frame, a new frame pops up with a "t"

When I do it in a full-screen frame, a new frame pops up but a "t' is in
the OLD frame.  And then (I think) with some delay it also appears in the
NEW frame.

>
> report?  Is the message shown in both frames?
>
> Does 'foo' specified as
>
> (defun foo ()
>    (interactive)
>    (let ((frame (make-frame)))
>      (select-frame-set-input-focus frame)))
>
> behave the same way?


I get a "nil" in both frames.  Hard to tell if it's simulataneous (as I
cannot look at them at the same time) and maybe switching desktops triggers
something.

  Does
>
> (add-hook 'after-make-frame-functions 'select-frame-set-input-focus)
>
> change anything?


Not really.  When I make a new frame, a new frame on a new desktop appears,
but typing M-x shows no change on screen.  When I switch back to the
original screen M-x shows on screen AND when I switch again NOW I can see
M-x prompt on the new screen as well.


  Does
>
> (add-hook 'after-make-frame-functions 'redirect-frame-focus)
>
> change anything?
>

No.  Same behavior as after the other add-hook.

Another oddity (or is it expected): when I switch back-and-forth between
desktops having typed M-x, on one screen the focus (selected window?) is on
the M-x line and on the other on *scratch* (where I originally ran the C-x
5 2 command).  Not sure which is which by now...

Actually, after a few switches back and forth, the M-x line is the selected
window in the frame where I typed it (new frame) and it's not selected in
the old frame.

Not sure if this helps in any way.

–Boris

>
> martin
>

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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Boris Aronov <aronov.boris <at> gmail.com>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 78527 <at> debbugs.gnu.org
Subject: Re: bug#78527: 30.1; Mishaving new frame creation in MacOS on new
 desktop
Date: Wed, 4 Jun 2025 10:47:33 +0200

Thanks for answering.

I'm still a bit dense in the following sense: You have a fullscreen
frame, do C-x 5 2 and now see the new frame on a new desktop but it
apparently didn't get focus because, as you say, the prompt doesn't
appear there.  However, in your initial posting you say that "Focus
shifts there".  What makes you think that focus shifted there?  The
appearance of the cursor, the mode line, some decoration in the new
frame?  Does C-x 2 split a window in the new or old frame?

>> I'd like to understand the focus issue.  What does C-x 5 o do when run
>> in the old frame?
>
>
> - Opened "Emacs -Q"
> - Clicked the green button (fullscreen)
> - C-x 5 2 (new frame opens on another desktop)
> - I swipe to original desktop
> - C-x 5 o switches to the new one and repeating it takes me back

Does C-x 5 o also switch the desktop you see?

> What does running 'foo' defined as
>>
>> (defun foo ()
>>     (interactive)
>>     (let ((frame (make-frame)))
>>       (sit-for 3)
>>       (message "%s" (frame-focus-state frame))))
>>
>
> When I do this in an non-full-screen frame, a new frame pops up with a "t"
>
> When I do it in a full-screen frame, a new frame pops up but a "t' is in
> the OLD frame.  And then (I think) with some delay it also appears in the
> NEW frame.

This "delay" should come from the (sit-for 3) call.

>> report?  Is the message shown in both frames?
>>
>> Does 'foo' specified as
>>
>> (defun foo ()
>>     (interactive)
>>     (let ((frame (make-frame)))
>>       (select-frame-set-input-focus frame)))
>>
>> behave the same way?
>
>
> I get a "nil" in both frames.

The nil would come from the return value of the frame focusing function
so my question was silly.  What I really meant with "behave the same
way" was whether the new frame does get input focus with this 'foo',
that is, whether now Emacs shows the prompt in the new frame when you
try executing a command.  I suppose the answer is "no".

> Hard to tell if it's simulataneous (as I
> cannot look at them at the same time) and maybe switching desktops triggers
> something.
>
>    Does
>>
>> (add-hook 'after-make-frame-functions 'select-frame-set-input-focus)
>>
>> change anything?
>
>
> Not really.  When I make a new frame, a new frame on a new desktop appears,
> but typing M-x shows no change on screen.  When I switch back to the
> original screen M-x shows on screen AND when I switch again NOW I can see
> M-x prompt on the new screen as well.
>
>
>    Does
>>
>> (add-hook 'after-make-frame-functions 'redirect-frame-focus)
>>
>> change anything?
>>
>
> No.  Same behavior as after the other add-hook.

I see.

> Another oddity (or is it expected): when I switch back-and-forth between
> desktops having typed M-x, on one screen the focus (selected window?) is on
> the M-x line and on the other on *scratch* (where I originally ran the C-x
> 5 2 command).  Not sure which is which by now...
>
> Actually, after a few switches back and forth, the M-x line is the selected
> window in the frame where I typed it (new frame) and it's not selected in
> the old frame.
>
> Not sure if this helps in any way.

Not yet.  If you have two normal (non-fullscreen) frames of the same
Emacs process on two different desktops, type a command so that a prompt
appears in one of them and then do C-x 5 o: Does the prompt move to the
other frame?  Right away?

BTW: Do you have Mission Control installed and active?  Maybe some
setting in it triggers the "put the frame on the other desktop because
the first one is too crowded" behavior.

martin

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

From: Boris Aronov <aronov.boris <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 78527 <at> debbugs.gnu.org
Subject: Re: bug#78527: 30.1;
 Mishaving new frame creation in MacOS on new desktop
Date: Wed, 4 Jun 2025 19:17:50 +0200

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

Hi Martin,

On Wed, Jun 4, 2025 at 10:47 AM martin rudalics <rudalics <at> gmx.at> wrote:

> Thanks for answering.
>
> I'm still a bit dense in the following sense: You have a fullscreen
> frame, do C-x 5 2 and now see the new frame on a new desktop but it
> apparently didn't get focus because, as you say, the prompt doesn't
> appear there.  However, in your initial posting you say that "Focus
> shifts there".  What makes you think that focus shifted there?  The
> appearance of the cursor, the mode line, some decoration in the new
> frame?  Does C-x 2 split a window in the new or old frame?
>

C-x 2: New frame, surprisingly.  But subsequent commands are still messed
up.  For example, after C-x 2 I now have 2 windows in the new frame, but if
I try M-x, the prompt shows up the old frame!  That's without trying any of
the hooks you suggested.

Focus: Sorry.  I did not use the right terminology.  I only at the moment
work on my laptop with a single physical screen.  So when a "new frame
opens on new desktop",  what I see on my physical screen is the old desktop
slides off to the left and a new desktop with a new frame appears.  I
probably should not have used the word "focus."  I get a new frame with a
highlighted cursor in the main window.

Just noticed another weirdness, btw:
– I see a blinking cursor with emacs -Q.
– But after I have two frames in different desktops, immediately after I
switch between desktops (in either direction), the cursor is highlighted,
but does not blink.
– In fact, this cursor thing has nothing to do with full screen or
desktops: with two regular frames next to each other on a common desktop,
when *I click on a frame to switch focus there*, the cursor gets
highlighted, but does not blink until I do something...  *But if I do C-x 5
2 to switch frames, *it blinks as it should.  And when I switch from
Firefox (where I am writing this) to Emacs (using Alt-TAB [=command-TAB]),
the cursor initially does not blink.

Another experiment (similar to what I wrote in an earlier email): Do the
C-x 5 2 from a full-screen frame.  Do a M-x.  I do *not* see the prompt.
Now use MacOS shortcut keys to switch frames (ctrl-right/left).  Then the
M-x prompt appears in BOTH frames.  In one it is selected (cursor is
highlighted) and in the other it is not (highlighted cursor is in the main
*scratch* window).  This is w/o any of the hooks you wanted me to try.
Just plain Macports Emacs -Q.

Hope this helps,
  –Boris



>  >> I'd like to understand the focus issue.  What does C-x 5 o do when run
>  >> in the old frame?
>  >
>  >
>  > - Opened "Emacs -Q"
>  > - Clicked the green button (fullscreen)
>  > - C-x 5 2 (new frame opens on another desktop)
>  > - I swipe to original desktop
>  > - C-x 5 o switches to the new one and repeating it takes me back
>
> Does C-x 5 o also switch the desktop you see?
>
>  > What does running 'foo' defined as
>  >>
>  >> (defun foo ()
>  >>     (interactive)
>  >>     (let ((frame (make-frame)))
>  >>       (sit-for 3)
>  >>       (message "%s" (frame-focus-state frame))))
>  >>
>  >
>  > When I do this in an non-full-screen frame, a new frame pops up with a
> "t"
>  >
>  > When I do it in a full-screen frame, a new frame pops up but a "t' is in
>  > the OLD frame.  And then (I think) with some delay it also appears in
> the
>  > NEW frame.
>
> This "delay" should come from the (sit-for 3) call.
>
>  >> report?  Is the message shown in both frames?
>  >>
>  >> Does 'foo' specified as
>  >>
>  >> (defun foo ()
>  >>     (interactive)
>  >>     (let ((frame (make-frame)))
>  >>       (select-frame-set-input-focus frame)))
>  >>
>  >> behave the same way?
>  >
>  >
>  > I get a "nil" in both frames.
>
> The nil would come from the return value of the frame focusing function
> so my question was silly.  What I really meant with "behave the same
> way" was whether the new frame does get input focus with this 'foo',
> that is, whether now Emacs shows the prompt in the new frame when you
> try executing a command.  I suppose the answer is "no".
>
>  > Hard to tell if it's simulataneous (as I
>  > cannot look at them at the same time) and maybe switching desktops
> triggers
>  > something.
>  >
>  >    Does
>  >>
>  >> (add-hook 'after-make-frame-functions 'select-frame-set-input-focus)
>  >>
>  >> change anything?
>  >
>  >
>  > Not really.  When I make a new frame, a new frame on a new desktop
> appears,
>  > but typing M-x shows no change on screen.  When I switch back to the
>  > original screen M-x shows on screen AND when I switch again NOW I can
> see
>  > M-x prompt on the new screen as well.
>  >
>  >
>  >    Does
>  >>
>  >> (add-hook 'after-make-frame-functions 'redirect-frame-focus)
>  >>
>  >> change anything?
>  >>
>  >
>  > No.  Same behavior as after the other add-hook.
>
> I see.
>
>  > Another oddity (or is it expected): when I switch back-and-forth between
>  > desktops having typed M-x, on one screen the focus (selected window?)
> is on
>  > the M-x line and on the other on *scratch* (where I originally ran the
> C-x
>  > 5 2 command).  Not sure which is which by now...
>  >
>  > Actually, after a few switches back and forth, the M-x line is the
> selected
>  > window in the frame where I typed it (new frame) and it's not selected
> in
>  > the old frame.
>  >
>  > Not sure if this helps in any way.
>
> Not yet.  If you have two normal (non-fullscreen) frames of the same
> Emacs process on two different desktops, type a command so that a prompt
> appears in one of them and then do C-x 5 o: Does the prompt move to the
> other frame?  Right away?
>
> BTW: Do you have Mission Control installed and active?  Maybe some
> setting in it triggers the "put the frame on the other desktop because
> the first one is too crowded" behavior.
>
> martin
>

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Boris Aronov <aronov.boris <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, rudalics <at> gmx.at, 78527 <at> debbugs.gnu.org
Subject: Re: bug#78527: 30.1;
 Mishaving new frame creation in MacOS on new desktop
Date: Thu, 05 Jun 2025 08:15:25 +0300

> From: Boris Aronov <aronov.boris <at> gmail.com>
> Date: Wed, 4 Jun 2025 19:17:50 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Gerd Möllmann <gerd.moellmann <at> gmail.com>, 
> 	78527 <at> debbugs.gnu.org
> 
> Just noticed another weirdness, btw: 
> – I see a blinking cursor with emacs -Q.  
> – But after I have two frames in different desktops, immediately after I switch between desktops (in either
> direction), the cursor is highlighted, but does not blink.
> – In fact, this cursor thing has nothing to do with full screen or desktops: with two regular frames next to each
> other on a common desktop, when I click on a frame to switch focus there, the cursor gets highlighted,
> but does not blink until I do something...  But if I do C-x 5 2 to switch frames, it blinks as it should.  And
> when I switch from Firefox (where I am writing this) to Emacs (using Alt-TAB [=command-TAB]), the cursor
> initially does not blink.

I'm not sure the blinking cursor part is related.  The way it works is
that blink-cursor-check is added to post-command-hook, and
blink-cursor--rescan-frames is added to after-delete-frame-functions
and as an advice to after-focus-change-function.  If the cursor
doesn't start blinking when a frame receives focus, it means neither
of these hooks is called in your configuration, for some reason.  For
example, clicking on a frame to switch focus probably doesn't call
after-focus-change-function.

You can see how blink-cursor-mode works in frame.el.  Using
trace-function to trace execution of the relevant functions should
allow you to figure out what does not happen on your system that
should have happened to allow the cursor to start blinking after
switching frames or creating a new frame.

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

From: Boris Aronov <aronov.boris <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, rudalics <at> gmx.at, 78527 <at> debbugs.gnu.org
Subject: Re: bug#78527: 30.1;
 Mishaving new frame creation in MacOS on new desktop
Date: Thu, 5 Jun 2025 07:42:34 +0200

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

Thank you, Eli.  I will try to look into this, when I get a chance.  I was
just wondering if the whole misbehavior is connected to focus issues.
Meanwhile if I can provide more information about the other mystery, I
would be happy to do so.  Emacs 31 mostly works OK on MacOS (once in a
while it seems to forget to echo a character typed until the next
character is entered and a few other oddities), but this new-frame behavior
is annoying, as I have developed a habit, when I need to do something new
and unrelated and perhaps short, to make a new frame, take care of things
there and then remove the frame.  The current behavior is interfering with
that.

–Boris

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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Boris Aronov <aronov.boris <at> gmail.com>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 78527 <at> debbugs.gnu.org
Subject: Re: bug#78527: 30.1; Mishaving new frame creation in MacOS on new
 desktop
Date: Thu, 5 Jun 2025 11:05:45 +0200

>> I'm still a bit dense in the following sense: You have a fullscreen
>> frame, do C-x 5 2 and now see the new frame on a new desktop but it
>> apparently didn't get focus because, as you say, the prompt doesn't
>> appear there.  However, in your initial posting you say that "Focus
>> shifts there".  What makes you think that focus shifted there?  The
>> appearance of the cursor, the mode line, some decoration in the new
>> frame?  Does C-x 2 split a window in the new or old frame?
>>
>
> C-x 2: New frame, surprisingly.

Not really.  C-x 2 splits the selected window and that's the one on the
new frame.  The C-x 5 2 need _not_ necessarily have made the new frame
the selected one but it apparently does so on your system.  On many
systems, the window manager gives users the choice whether a freshly
created window should automatically become "active", that is, has
keystrokes directed to it.  In your case we apparently have a split
behavior - the new frame becomes selected but focus remains on the old
frame.

> But subsequent commands are still messed
> up.  For example, after C-x 2 I now have 2 windows in the new frame, but if
> I try M-x, the prompt shows up the old frame!

You would have to trace choose_minibuf_frame in minibuf.c to find out
why Emacs shows the prompt in the old frame.  I'm afraid you won't be
able to do that.  Try the following instead: With a fullscreen Emacs
showing *scratch* insert the following text

(setq old-frame (selected-frame))
(setq new-frame (make-frame))

(defun foo ()
  (interactive)
  (insert
   (format "selected: % s old: %s new: %s old-mw: %s new-mw: %s"
	   (selected-frame) old-frame new-frame
	   (window-frame (minibuffer-window old-frame))
	   (window-frame (minibuffer-window new-frame)))))

(global-set-key [(control l)] 'foo)

do M-x RET eval-buffer RET and then type C-l.  The text this adds to
+scratch* might tell us which minibuffer window Emacs wants to use.

> That's without trying any of
> the hooks you suggested.
>
> Focus: Sorry.  I did not use the right terminology.  I only at the moment
> work on my laptop with a single physical screen.  So when a "new frame
> opens on new desktop",  what I see on my physical screen is the old desktop
> slides off to the left and a new desktop with a new frame appears.  I
> probably should not have used the word "focus."  I get a new frame with a
> highlighted cursor in the main window.

This again only indicates that Emacs considers the new frame as the
selected one.  Here on xfce WM windows have decorations showing which
window the WM considers as the one having focus - where it directs
keystrokes to.  Does your bad scenario happen with an initially
"maximized" (not "fullboth") frame too?  Then maybe such decorations
would reveal more information.

> Just noticed another weirdness, btw:
> – I see a blinking cursor with emacs -Q.
> – But after I have two frames in different desktops, immediately after I
> switch between desktops (in either direction), the cursor is highlighted,
> but does not blink.
> – In fact, this cursor thing has nothing to do with full screen or
> desktops: with two regular frames next to each other on a common desktop,
> when *I click on a frame to switch focus there*, the cursor gets
> highlighted, but does not blink until I do something...  *But if I do C-x 5
> 2 to switch frames, *it blinks as it should.  And when I switch from
> Firefox (where I am writing this) to Emacs (using Alt-TAB [=command-TAB]),
> the cursor initially does not blink.

This further indicates a problem with what Emacs thinks about which of
its frames has focus.

> Another experiment (similar to what I wrote in an earlier email): Do the
> C-x 5 2 from a full-screen frame.  Do a M-x.  I do *not* see the prompt.
> Now use MacOS shortcut keys to switch frames (ctrl-right/left).  Then the
> M-x prompt appears in BOTH frames.

But you can't tell since you can see only one frame at a time.  What is
your value of 'minibuffer-follows-selected-frame'?  Does changing it
change the behavior you see?

> In one it is selected (cursor is
> highlighted)

Is "it" the minibuffer window or just the frame?

> and in the other it is not (highlighted cursor is in the main
> *scratch* window).  This is w/o any of the hooks you wanted me to try.
> Just plain Macports Emacs -Q.

Again this hints at a focus problem.  We would have to understand how
focusing works on MacOS.  You could try with

(defun foo-it (&rest rest)
  (with-current-buffer (get-buffer-create "*foo*")
    (goto-char (point-max))
    (when rest
      (insert (format "%s" (car rest)))
      (setq rest (cdr rest))
      (while rest
	(insert (format " .. %s" (car rest)))
	(setq rest (cdr rest)))
      (insert "\n"))))

(defun my-foo-it ()
  (let ((frames (frame-list))
	frame foo)
    (while frames
      (setq frame (car frames))
      (setq foo (cons (cons frame (frame-focus-state frame)) foo))
      (setq frames (cdr frames)))
    (foo-it foo)))

(add-function :after after-focus-change-function #'my-foo-it)

and tell us what the buffer *foo* contains after C-x 5 2.  The focus
handling code has changed in Emacs a couple of years ago and I have no
idea whether 'frame-focus-state' is useful at all.

martin

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 78527 <at> debbugs.gnu.org,
 Boris Aronov <aronov.boris <at> gmail.com>
Subject: Re: bug#78527: 30.1;
 Mishaving new frame creation in MacOS on new desktop
Date: Thu, 5 Jun 2025 07:49:23 -0400

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

On Thu, Jun 5, 2025 at 5:06 AM martin rudalics via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:

>  >> I'm still a bit dense in the following sense: You have a fullscreen
>  >> frame, do C-x 5 2 and now see the new frame on a new desktop but it
>  >> apparently didn't get focus because, as you say, the prompt doesn't
>  >> appear there.  However, in your initial posting you say that "Focus
>  >> shifts there".  What makes you think that focus shifted there?  The
>  >> appearance of the cursor, the mode line, some decoration in the new
>  >> frame?  Does C-x 2 split a window in the new or old frame?
>  >>
>  >
>  > C-x 2: New frame, surprisingly.
>
> Not really.  C-x 2 splits the selected window and that's the one on the
> new frame.  The C-x 5 2 need _not_ necessarily have made the new frame
> the selected one but it apparently does so on your system.  On many
> systems, the window manager gives users the choice whether a freshly
> created window should automatically become "active", that is, has
> keystrokes directed to it.  In your case we apparently have a split
> behavior - the new frame becomes selected but focus remains on the old
> frame.
>
>  > But subsequent commands are still messed
>  > up.  For example, after C-x 2 I now have 2 windows in the new frame,
> but if
>  > I try M-x, the prompt shows up the old frame!
>
> You would have to trace choose_minibuf_frame in minibuf.c to find out
> why Emacs shows the prompt in the old frame.  I'm afraid you won't be
> able to do that.  Try the following instead: With a fullscreen Emacs
> showing *scratch* insert the following text
>
> (setq old-frame (selected-frame))
> (setq new-frame (make-frame))
>
> (defun foo ()
>    (interactive)
>    (insert
>     (format "selected: % s old: %s new: %s old-mw: %s new-mw: %s"
>            (selected-frame) old-frame new-frame
>            (window-frame (minibuffer-window old-frame))
>            (window-frame (minibuffer-window new-frame)))))
>
> (global-set-key [(control l)] 'foo)
>
> do M-x RET eval-buffer RET and then type C-l.  The text this adds to
> +scratch* might tell us which minibuffer window Emacs wants to use.
>
>  > That's without trying any of
>  > the hooks you suggested.
>  >
>  > Focus: Sorry.  I did not use the right terminology.  I only at the
> moment
>  > work on my laptop with a single physical screen.  So when a "new frame
>  > opens on new desktop",  what I see on my physical screen is the old
> desktop
>  > slides off to the left and a new desktop with a new frame appears.  I
>  > probably should not have used the word "focus."  I get a new frame with
> a
>  > highlighted cursor in the main window.
>
> This again only indicates that Emacs considers the new frame as the
> selected one.  Here on xfce WM windows have decorations showing which
> window the WM considers as the one having focus - where it directs
> keystrokes to.  Does your bad scenario happen with an initially
> "maximized" (not "fullboth") frame too?  Then maybe such decorations
> would reveal more information.
>
>  > Just noticed another weirdness, btw:
>  > – I see a blinking cursor with emacs -Q.
>  > – But after I have two frames in different desktops, immediately after I
>  > switch between desktops (in either direction), the cursor is
> highlighted,
>  > but does not blink.
>  > – In fact, this cursor thing has nothing to do with full screen or
>  > desktops: with two regular frames next to each other on a common
> desktop,
>  > when *I click on a frame to switch focus there*, the cursor gets
>  > highlighted, but does not blink until I do something...  *But if I do
> C-x 5
>  > 2 to switch frames, *it blinks as it should.  And when I switch from
>  > Firefox (where I am writing this) to Emacs (using Alt-TAB
> [=command-TAB]),
>  > the cursor initially does not blink.
>
> This further indicates a problem with what Emacs thinks about which of
> its frames has focus.
>
>  > Another experiment (similar to what I wrote in an earlier email): Do the
>  > C-x 5 2 from a full-screen frame.  Do a M-x.  I do *not* see the prompt.
>  > Now use MacOS shortcut keys to switch frames (ctrl-right/left).  Then
> the
>  > M-x prompt appears in BOTH frames.
>
> But you can't tell since you can see only one frame at a time.  What is
> your value of 'minibuffer-follows-selected-frame'?  Does changing it
> change the behavior you see?
>
>  > In one it is selected (cursor is
>  > highlighted)
>
> Is "it" the minibuffer window or just the frame?
>
>  > and in the other it is not (highlighted cursor is in the main
>  > *scratch* window).  This is w/o any of the hooks you wanted me to try.
>  > Just plain Macports Emacs -Q.
>
> Again this hints at a focus problem.  We would have to understand how
> focusing works on MacOS.  You could try with
>
> (defun foo-it (&rest rest)
>    (with-current-buffer (get-buffer-create "*foo*")
>      (goto-char (point-max))
>      (when rest
>        (insert (format "%s" (car rest)))
>        (setq rest (cdr rest))
>        (while rest
>         (insert (format " .. %s" (car rest)))
>         (setq rest (cdr rest)))
>        (insert "\n"))))
>
> (defun my-foo-it ()
>    (let ((frames (frame-list))
>         frame foo)
>      (while frames
>        (setq frame (car frames))
>        (setq foo (cons (cons frame (frame-focus-state frame)) foo))
>        (setq frames (cdr frames)))
>      (foo-it foo)))
>
> (add-function :after after-focus-change-function #'my-foo-it)
>
> and tell us what the buffer *foo* contains after C-x 5 2.  The focus
> handling code has changed in Emacs a couple of years ago and I have no
> idea whether 'frame-focus-state' is useful at all.
>

Boris,

Mac is my primary system but I don't use Mission Control or Spaces.
However, I am aware that one can alter the Dock's behavior (MC is a part of
Dock.app) and it could be this that is influencing Emacs behavior rather
than Emacs itself.

In System Preferences...Mission Control... have you tried frame-creation
with the second option, below checked and unchecked?  And also Group
checked and unchecked?

[image: image.png]

-Stéphane

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

[image.png (image/png, inline)]

Previous Next

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