GNU bug report logs - #76814
31.0.50; NS initial frame not raised

Previous Next

To reply to this bug, email your comments to 76814 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: Ship Mints <shipmints <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; NS initial frame not raised
Date: Fri, 7 Mar 2025 11:56:50 -0500

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

This is a behavior difference from 29 and 30.  In my init, I have to
manually raise the initial frame to avoid having to search for the new
frame using the Mac app switcher.

-Stephane

In GNU Emacs 31.0.50 (build 50, x86_64-apple-darwin21.6.0, NS
 appkit-2113.65 Version 12.7.6 (Build 21H1320)) of 2025-03-07 built on
 tlok.local
Repository revision: e35435daf392462440bbc51a5b82d93eea7757c6
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.7.6

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG LCMS2 LIBXML2 MODULES 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: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  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
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: 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 mail-extr emacsbug lisp-mnt message mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils 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 tty-child-frames emacs)

Memory information:
((conses 16 40162 9402) (symbols 48 5348 0) (strings 32 12361 1651)
 (string-bytes 1 303863) (vectors 16 9682)
 (vector-slots 8 110223 7824) (floats 8 22 7) (intervals 56 355 0)
 (buffers 992 11))

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

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Ship Mints <shipmints <at> gmail.com>, 76814 <at> debbugs.gnu.org
Cc: Alan Third <alan <at> idiocy.org>
Subject: Re: bug#76814: 31.0.50; NS initial frame not raised
Date: Fri, 7 Mar 2025 20:10:54 +0000

Ship Mints <shipmints <at> gmail.com> writes:

> This is a behavior difference from 29 and 30.  In my init, I have to
> manually raise the initial frame to avoid having to search for the new
> frame using the Mac app switcher.

I see this behavior with Emacs 28 and 29 too, when starting Emacs from a
terminal window.  BTW, what is the workaround that you're using?

Looking into this a little bit, I did find this API:

    [main_window makeKeyAndOrderFront:nil];

https://developer.apple.com/documentation/appkit/nswindow/makekeyandorderfront(_:)

Alan, do you have any ideas or suggestions here?

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

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Alan Third <alan <at> idiocy.org>, 76814 <at> debbugs.gnu.org
Subject: Re: bug#76814: 31.0.50; NS initial frame not raised
Date: Fri, 7 Mar 2025 15:12:34 -0500

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

On Fri, Mar 7, 2025 at 3:10 PM Stefan Kangas <stefankangas <at> gmail.com> wrote:

> Ship Mints <shipmints <at> gmail.com> writes:
>
> > This is a behavior difference from 29 and 30.  In my init, I have to
> > manually raise the initial frame to avoid having to search for the new
> > frame using the Mac app switcher.
>
> I see this behavior with Emacs 28 and 29 too, when starting Emacs from a
> terminal window.  BTW, what is the workaround that you're using?
>
> Looking into this a little bit, I did find this API:
>
>     [main_window makeKeyAndOrderFront:nil];
>
>
> https://developer.apple.com/documentation/appkit/nswindow/makekeyandorderfront(_
> :)
>
> Alan, do you have any ideas or suggestions here?
>

Pretty much this:

  (add-hook 'window-setup-hook
            (lambda ()
              (select-frame-set-input-focus (selected-frame)))

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

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

From: Alan Third <alan <at> idiocy.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Ship Mints <shipmints <at> gmail.com>, 76814 <at> debbugs.gnu.org
Subject: Re: bug#76814: 31.0.50; NS initial frame not raised
Date: Fri, 7 Mar 2025 20:48:06 +0000

On Fri, Mar 07, 2025 at 08:10:54PM +0000, Stefan Kangas wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
> 
> > This is a behavior difference from 29 and 30.  In my init, I have to
> > manually raise the initial frame to avoid having to search for the new
> > frame using the Mac app switcher.
> 
> I see this behavior with Emacs 28 and 29 too, when starting Emacs from a
> terminal window.  BTW, what is the workaround that you're using?
> 
> Looking into this a little bit, I did find this API:
> 
>     [main_window makeKeyAndOrderFront:nil];
> 
> https://developer.apple.com/documentation/appkit/nswindow/makekeyandorderfront(_:)
> 
> Alan, do you have any ideas or suggestions here?

Not really. I do remember there was a bug report years ago about
new frames not being selected correctly. IIRC we never got to the
bottom of it... Bug#47731. I'm not sure this is the same thing, but
it sounds similar.

Why it would suddenly be more of an issue in Emacs 30? I've no idea.
-- 
Alan Third

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

From: Ship Mints <shipmints <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Stefan Kangas <stefankangas <at> gmail.com>, 
 Ship Mints <shipmints <at> gmail.com>, 76814 <at> debbugs.gnu.org
Subject: Re: bug#76814: 31.0.50; NS initial frame not raised
Date: Fri, 7 Mar 2025 15:53:59 -0500

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

On Fri, Mar 7, 2025 at 3:48 PM Alan Third <alan <at> idiocy.org> wrote:

> On Fri, Mar 07, 2025 at 08:10:54PM +0000, Stefan Kangas wrote:
> > Ship Mints <shipmints <at> gmail.com> writes:
> >
> > > This is a behavior difference from 29 and 30.  In my init, I have to
> > > manually raise the initial frame to avoid having to search for the new
> > > frame using the Mac app switcher.
> >
> > I see this behavior with Emacs 28 and 29 too, when starting Emacs from a
> > terminal window.  BTW, what is the workaround that you're using?
> >
> > Looking into this a little bit, I did find this API:
> >
> >     [main_window makeKeyAndOrderFront:nil];
> >
> >
> https://developer.apple.com/documentation/appkit/nswindow/makekeyandorderfront(_
> :)
> >
> > Alan, do you have any ideas or suggestions here?
>
> Not really. I do remember there was a bug report years ago about
> new frames not being selected correctly. IIRC we never got to the
> bottom of it... Bug#47731. I'm not sure this is the same thing, but
> it sounds similar.
>
> Why it would suddenly be more of an issue in Emacs 30? I've no idea.
>

I just tested my 29.4 and it works fine.  I see Gerd added:

  @interface EmacsView : NSView <NSTextInput, NSTextInputClient,
NSWindowDelegate>

where 29.4 was:

  @interface EmacsView : NSView <NSTextInput, NSWindowDelegate>

It's not obvious to me why that would matter but that's the most immediate
thing that jumps out.

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

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

From: Ship Mints <shipmints <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Stefan Kangas <stefankangas <at> gmail.com>, 
 Ship Mints <shipmints <at> gmail.com>, 76814 <at> debbugs.gnu.org
Subject: Re: bug#76814: 31.0.50; NS initial frame not raised
Date: Fri, 7 Mar 2025 15:57:39 -0500

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

On Fri, Mar 7, 2025 at 3:53 PM Ship Mints <shipmints <at> gmail.com> wrote:

> On Fri, Mar 7, 2025 at 3:48 PM Alan Third <alan <at> idiocy.org> wrote:
>
>> On Fri, Mar 07, 2025 at 08:10:54PM +0000, Stefan Kangas wrote:
>> > Ship Mints <shipmints <at> gmail.com> writes:
>> >
>> > > This is a behavior difference from 29 and 30.  In my init, I have to
>> > > manually raise the initial frame to avoid having to search for the new
>> > > frame using the Mac app switcher.
>> >
>> > I see this behavior with Emacs 28 and 29 too, when starting Emacs from a
>> > terminal window.  BTW, what is the workaround that you're using?
>> >
>> > Looking into this a little bit, I did find this API:
>> >
>> >     [main_window makeKeyAndOrderFront:nil];
>> >
>> >
>> https://developer.apple.com/documentation/appkit/nswindow/makekeyandorderfront(_
>> :)
>> >
>> > Alan, do you have any ideas or suggestions here?
>>
>> Not really. I do remember there was a bug report years ago about
>> new frames not being selected correctly. IIRC we never got to the
>> bottom of it... Bug#47731. I'm not sure this is the same thing, but
>> it sounds similar.
>>
>> Why it would suddenly be more of an issue in Emacs 30? I've no idea.
>>
>
> I just tested my 29.4 and it works fine.  I see Gerd added:
>
>   @interface EmacsView : NSView <NSTextInput, NSTextInputClient,
> NSWindowDelegate>
>
> where 29.4 was:
>
>   @interface EmacsView : NSView <NSTextInput, NSWindowDelegate>
>
> It's not obvious to me why that would matter but that's the most immediate
> thing that jumps out.
>

I built master without NSTextInputClient and still the same so that's a red
herring.

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

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

From: Ship Mints <shipmints <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Stefan Kangas <stefankangas <at> gmail.com>, 
 Ship Mints <shipmints <at> gmail.com>, 76814 <at> debbugs.gnu.org
Subject: Re: bug#76814: 31.0.50; NS initial frame not raised
Date: Fri, 7 Mar 2025 16:14:57 -0500

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

On Fri, Mar 7, 2025 at 3:57 PM Ship Mints <shipmints <at> gmail.com> wrote:

> On Fri, Mar 7, 2025 at 3:53 PM Ship Mints <shipmints <at> gmail.com> wrote:
>
>> On Fri, Mar 7, 2025 at 3:48 PM Alan Third <alan <at> idiocy.org> wrote:
>>
>>> On Fri, Mar 07, 2025 at 08:10:54PM +0000, Stefan Kangas wrote:
>>> > Ship Mints <shipmints <at> gmail.com> writes:
>>> >
>>> > > This is a behavior difference from 29 and 30.  In my init, I have to
>>> > > manually raise the initial frame to avoid having to search for the
>>> new
>>> > > frame using the Mac app switcher.
>>> >
>>> > I see this behavior with Emacs 28 and 29 too, when starting Emacs from
>>> a
>>> > terminal window.  BTW, what is the workaround that you're using?
>>> >
>>> > Looking into this a little bit, I did find this API:
>>> >
>>> >     [main_window makeKeyAndOrderFront:nil];
>>> >
>>> >
>>> https://developer.apple.com/documentation/appkit/nswindow/makekeyandorderfront(_
>>> :)
>>> >
>>> > Alan, do you have any ideas or suggestions here?
>>>
>>> Not really. I do remember there was a bug report years ago about
>>> new frames not being selected correctly. IIRC we never got to the
>>> bottom of it... Bug#47731. I'm not sure this is the same thing, but
>>> it sounds similar.
>>>
>>> Why it would suddenly be more of an issue in Emacs 30? I've no idea.
>>>
>>
>> I just tested my 29.4 and it works fine.  I see Gerd added:
>>
>>   @interface EmacsView : NSView <NSTextInput, NSTextInputClient,
>> NSWindowDelegate>
>>
>> where 29.4 was:
>>
>>   @interface EmacsView : NSView <NSTextInput, NSWindowDelegate>
>>
>> It's not obvious to me why that would matter but that's the most
>> immediate thing that jumps out.
>>
>
> I built master without NSTextInputClient and still the same so that's a
> red herring.
>

This might be another red herring but it's possible some changes are also
related to this claim that macOS dictation broke
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76765

I tested 29.4 and dictation didn't work for me.  I see people on reddit
talking about it claiming it worked.  I have a feeling they were all using
emacs-mac which uses a different code base than GNU Emacs.

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

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Ship Mints <shipmints <at> gmail.com>, Alan Third <alan <at> idiocy.org>,
 76814 <at> debbugs.gnu.org
Subject: Re: bug#76814: 31.0.50; NS initial frame not raised
Date: Mon, 10 Mar 2025 17:40:48 -0700

Ship Mints <shipmints <at> gmail.com> writes:

> This might be another red herring but it's possible some changes are also
> related to this claim that macOS dictation broke
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76765
>
> I tested 29.4 and dictation didn't work for me.  I see people on reddit
> talking about it claiming it worked.  I have a feeling they were all using
> emacs-mac which uses a different code base than GNU Emacs.

Could you please add these details to Bug#76765, and also ask the OP for
more information regarding which exact build of Emacs 29 he has tested?

Thanks in advance.

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

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Alan Third <alan <at> idiocy.org>, 76814 <at> debbugs.gnu.org
Subject: Re: bug#76814: 31.0.50; NS initial frame not raised
Date: Tue, 11 Mar 2025 09:09:21 -0400

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

On Mon, Mar 10, 2025 at 8:40 PM Stefan Kangas <stefankangas <at> gmail.com>
wrote:

> Ship Mints <shipmints <at> gmail.com> writes:
>
> > This might be another red herring but it's possible some changes are also
> > related to this claim that macOS dictation broke
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76765
> >
> > I tested 29.4 and dictation didn't work for me.  I see people on reddit
> > talking about it claiming it worked.  I have a feeling they were all
> using
> > emacs-mac which uses a different code base than GNU Emacs.
>
> Could you please add these details to Bug#76765, and also ask the OP for
> more information regarding which exact build of Emacs 29 he has tested?
>

I asked last week.  More than one person complained but the level of
information precision is low.

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

Previous Next

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