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

Previous Next

Package: emacs;

Reported by: Boris Aronov <aronov.boris <at> gmail.com>

Date: Wed, 21 May 2025 07:04:02 UTC

Severity: normal

Found in version 30.1

Full log


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




This bug report was last modified 6 days ago.

Previous Next


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