[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69525: 30.0.50; MacOS: New warnings on stderr
From: |
Gerd Möllmann |
Subject: |
bug#69525: 30.0.50; MacOS: New warnings on stderr |
Date: |
Mon, 04 Mar 2024 14:48:52 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Alan Third <alan@idiocy.org> writes:
> On Sun, Mar 03, 2024 at 06:36:29PM +0100, Gerd Möllmann wrote:
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>> > Eli Zaretskii <eliz@gnu.org> writes:
>> >
>> >>> From: Gerd Möllmann <gerd.moellmann@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.
- bug#69525: 30.0.50; MacOS: New warnings on stderr, Gerd Möllmann, 2024/03/03
- bug#69525: 30.0.50; MacOS: New warnings on stderr, Eli Zaretskii, 2024/03/03
- bug#69525: 30.0.50; MacOS: New warnings on stderr, Gerd Möllmann, 2024/03/03
- bug#69525: 30.0.50; MacOS: New warnings on stderr,
Gerd Möllmann <=
- bug#69525: 30.0.50; MacOS: New warnings on stderr, Gerd Möllmann, 2024/03/04
- bug#69525: 30.0.50; MacOS: New warnings on stderr, Alan Third, 2024/03/04
- bug#69525: 30.0.50; MacOS: New warnings on stderr, Gerd Möllmann, 2024/03/04
- bug#69525: 30.0.50; MacOS: New warnings on stderr, Alan Third, 2024/03/05
- bug#69525: 30.0.50; MacOS: New warnings on stderr, Gerd Möllmann, 2024/03/05
- bug#69525: 30.0.50; MacOS: New warnings on stderr, Gerd Möllmann, 2024/03/05