GNU bug report logs - #69525
30.0.50; MacOS: New warnings on stderr

Previous Next

Package: emacs;

Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Date: Sun, 3 Mar 2024 16:20:02 UTC

Severity: normal

Found in version 30.0.50

Fixed in version 30.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 69525 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#69525: 30.0.50; MacOS: New warnings on stderr
Date: Sun, 03 Mar 2024 20:29:32 +0100
Alan Third <alan <at> idiocy.org> writes:

> On Sun, Mar 03, 2024 at 06:36:29PM +0100, Gerd Möllmann wrote:
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>> 
>> > Eli Zaretskii <eliz <at> gnu.org> writes:
>> >
>> >>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> >>> Date: Sun, 03 Mar 2024 17:18:42 +0100
>> >>>
>> >>> The following warnings are printed to stderr, which I haven't seen
>> >>> previously. Maybe canBecomeKeyWindow should be implemented?
>> >>>
>> >>> 2024-03-03 17:10:16.334906+0100 emacs[12805:61381] [Window] Warning: -[NSWindow makeKeyWindow] called on EmacsWindow 0x7f7d90a34030 which returned NO from -[NSWindow canBecomeKeyWindow].
>
> Odd, Apple's documentation says:
>
>     The value of this property is YES if the window can become the key
>     window, otherwise, NO.
>     
>     Attempts to make the window the key window are abandoned if the
>     value of this property is NO. The value of this property is YES if
>     the window has a title bar or a resize bar, or NO otherwise.
>
> Is there anything unusual about your frames?

I have menu-bar-mode, toolbar-mode, scroll-bar-mode nil, and I use 1
frame in full screen.

I also tried to use tabs today. That's when I noticed the messagers,
because I started Emacs in LLDB to maybe get an impression where the
freezes come frame with tabs. (No luck so far.)

Don't know how tabs are implemented, maybe these are also some NS
widget/view?

>
>> >>> 2024-03-03 17:10:35.434255+0100 emacs[12805:61381] [CursorUI]
>-[TUINSCursorUIController activate:]: EmacsView doesn't conform to
>NSTextInputClient protocol.

This also appears when never using tabs in a session, BTW.

> I don't have the first clue about this one. NSTextInputClient has
> apparently been around since macOS 10.5, and I haven't heard of this
> problem before... EmacsView *should* conform to NSTextInputClient
> because it's a subclass of NSView.
>
>> >>
>> >> Alan, any ideas or suggestions?
>> >
>> > I think this could be related to tab-bar-mode (C-x t 2, ...), which I
>> > started using today. I'm also observing frequest beach balls (freezes)
>> > with tabs.
>> 
>> Beach balls of death, i.e. Emacs doesn't seem to recover.
>
> Please try reverting 6acb3c5b05a7b9fb32a5336e1bb740f527571ae9. I
> expect that'll fix the freezing, but I don't know about the others.

Thanks, I'll try that tomorrow.




This bug report was last modified 346 days ago.

Previous Next


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