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

Previous Next

Full log

View this message in rfc822 format

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: bug#69525: 30.0.50; MacOS: New warnings on stderr
Date: Mon, 04 Mar 2024 14:48:52 +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?

Found out how to reproduce this with emacs -Q. In scratch, eval

  (make-frame (list (cons 'parent-frame (selected-frame))
		    (cons 'no-accept-focus t)))

This looks to me like some function in ELPA package consult uses
no-accept-focus t, so that nsterm.m returns NO from canBecomeKeyWindow.
Consult with posframe seems to work anyway, so...

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

This doesn't seem to be related to the other warning. To reproduce,
start emacs -Q from a terminal and switch focus between Emacs and
Terminal.  Of course, I have no idea either what it means either.

>
>> >>
>> >> 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.

The commit didn't make a difference, as far as the 2 warnings are
concerned.

With the freezes I'm no step further, BTW, but that's a different
subject, I guess.

Previous Next

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