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

Previous Next

Full log

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

Previous Next

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