#78527 30.1; Mishaving new frame creation in MacOS on new desktop

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

Received: (at 78527) by debbugs.gnu.org; 5 Jun 2025 11:49:54 +0000
From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 05 07:49:54 2025
Received: from localhost ([127.0.0.1]:60007 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1uN96Y-0000HK-Jl
	for submit@debbugs.gnu.org; Thu, 05 Jun 2025 07:49:54 -0400
Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]:47244)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <shipmints@gmail.com>)
 id 1uN96W-0000Gt-Bm
 for 78527@debbugs.gnu.org; Thu, 05 Jun 2025 07:49:52 -0400
Received: by mail-qt1-x835.google.com with SMTP id
 d75a77b69052e-4a585dc5f4aso9990491cf.2
 for <78527@debbugs.gnu.org>; Thu, 05 Jun 2025 04:49:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1749124186; x=1749728986; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=H2CY+a2e7ZahJWBGyrOOycBGRcdTr4q5K1vTFLfGSkI=;
 b=NnK2y7QUNzR3mF/OkMMpaDEYKyvzhEscmBiM9SvJdhluzMHebSLx7ceJ927fuI5Naq
 jrm97ZR+sS6aUQanSNHDk17Ny39j22YpgUFaoIyTgwrsn0hH/xKbPtOG1WD9mMO2xvAO
 lqSqToEHJyokMC50+U4XR/ituZzszRwmBUms2avugfeIYVrvN926igg119PJ96ut4875
 eRN7L91BecY1ThM3mHhVVUvUEhOMk2AOGAkd0K7uH/LxWIArDbDYm+if0irqDNhcbL1r
 nk9YilJMdU7TbXdc7SXUzQsvF8/KQ1doocJTgR66Tww5HMb61pLLnVv2hBj/lKTXjhUt
 y+iA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1749124186; x=1749728986;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=H2CY+a2e7ZahJWBGyrOOycBGRcdTr4q5K1vTFLfGSkI=;
 b=daA6Hat8z+SYgFrYwlDdq3iM94waZa533Pqsxb6Fa60QAr/NjnOshHFJlSTE+xSCn7
 cocE3NGHCDnmgHE69qwigs9zDNZYG4Aa6H0DajoQWkOmbEgDuJ2SfbbQ9z/JmCbHE5/v
 AmSZailFtkmbPvxN42vBUIyT7w4bBTZVVpNpX6z4sWnEv9eGSEhprBg7Q6jnqCUKKj7K
 YubEZCRKuILqGBf9r91OHuLpy4M017Jd+/vfoWO9n/m/3xsq5v0hh7gFfgxz5HLaexwk
 3lz5nuon0nl+3EAtmM0nyAoIOmKIaUaw3nJP1xMe9o8ZzlMtf+KIdPu1GLBi+Kll5Pxg
 /jYg==
X-Forwarded-Encrypted: i=1;
 AJvYcCWTFHI2fgC4Inm89cEGIyCPMdROlH4R9izNAMOuFIDjiaMhp89lGBjqR4IvXAEO7Wsrr/bgJA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yz/j8G+pzROPb4HARgGNDfCAwJWrn1GBWOvtejuKFyGAmLCJ/an
 LxZf9S2wlWlC8T/zfhgzg4Xm3RZGE5zg+Odp2FUsUGhd3948Jx/M+k4/dKjYYDBCi1BJ6njkAa4
 YuIrKuVEB8Au5G5CSOrDuM2S/BetXl2FTs4Hn
X-Gm-Gg: ASbGncs0Xk6I+H0Ruy0TNTeaX3aUZ8kyx33R9FbXFl7cBNvckD86akJQbRIFiJyomqa
 DYGU23MFnGAymyF/d0iZFmY1QiC7EN922jerNiwpWc/G166mKTtVseqW+TZfnjLSMqw7hXqWnC2
 oAcVM/vt03i5KK4CrgbO4nbX6L53yE9vM2
X-Google-Smtp-Source: AGHT+IEpANGXpIMhibUi4WTdPQPU+Bb6aDDJGjRFW14oVwnZsu67VR6pCiC+WmlzhKGpzqMhTIg+j+FBue7GjAeMlY8=
X-Received: by 2002:a05:6102:e13:b0:4bb:e80b:473d with SMTP id
 ada2fe7eead31-4e746d55980mr4736893137.6.1749124176072; Thu, 05 Jun 2025
 04:49:36 -0700 (PDT)
MIME-Version: 1.0
References: <CAGPpUSoPzgd4bSKoAagQniBZoS+fhMZp0ZskoW5nA24VNxmtYg@mail.gmail.com>
 <865xht6k1e.fsf@gnu.org> <db4f94fe-a395-4ece-a9bb-6d763d7d0235@gmx.at>
 <CAGPpUSr-uyVcoOBMyEjVLSCp8+=RnkCiWyjw5afSs4XnkT9N=A@mail.gmail.com>
 <97dfdc42-d676-4cf0-a1cd-b248d441a6f7@gmx.at>
 <CAGPpUSrQDJmx=PEjJRpozzHZrQAD0S-fRCxNNhPB7ViAN4yfDA@mail.gmail.com>
 <db66688e-d099-467c-95be-e9d80a330544@gmx.at>
In-Reply-To: <db66688e-d099-467c-95be-e9d80a330544@gmx.at>
From: Stéphane Marks <shipmints@gmail.com>
Date: Thu, 5 Jun 2025 07:49:23 -0400
X-Gm-Features: AX0GCFtw_BspMwweRFGoyuwEk_u4t9ACnOT7WVb0RDGHeqwnO8QrgY1bus7bbAo
Message-ID: <CAN+1HboDc-vmEpx=8jijWh4WkwJpBpLG-taSeYe+dZqB_GjZOg@mail.gmail.com>
Subject: Re: bug#78527: 30.1;
 Mishaving new frame creation in MacOS on new desktop
To: martin rudalics <rudalics@gmx.at>
Content-Type: multipart/related; boundary="0000000000002ee8150636d1b5d8"
X-Debbugs-Envelope-To: 78527
Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
 Eli Zaretskii <eliz@gnu.org>, 78527@debbugs.gnu.org,
 Boris Aronov <aronov.boris@gmail.com>
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>

[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@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)]

Send a report that this bug log contains spam.