From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
To: Alan Third <alan@idiocy.org>
Cc: 69525@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: bug#69525: 30.0.50; MacOS: New warnings on stderr
Date: Mon, 04 Mar 2024 14:48:52 +0100 [thread overview]
Message-ID: <m2r0gqm7jv.fsf@Pro.fritz.box> (raw)
In-Reply-To: <ZeS8Kn7OXomoUeuE@idiocy.org> (Alan Third's message of "Sun, 3 Mar 2024 18:06:34 +0000")
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.
next prev parent reply other threads:[~2024-03-04 13:48 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-03 16:18 bug#69525: 30.0.50; MacOS: New warnings on stderr Gerd Möllmann
2024-03-03 16:26 ` Eli Zaretskii
2024-03-03 17:33 ` Gerd Möllmann
2024-03-03 17:36 ` Gerd Möllmann
2024-03-03 18:06 ` Alan Third
2024-03-03 19:29 ` Gerd Möllmann
2024-03-04 9:12 ` Gerd Möllmann
2024-03-04 13:48 ` Gerd Möllmann [this message]
2024-03-04 14:43 ` Gerd Möllmann
2024-03-04 21:40 ` Alan Third
2024-03-05 4:38 ` Gerd Möllmann
2024-03-05 12:59 ` Alan Third
2024-03-05 14:31 ` Gerd Möllmann
2024-03-05 5:31 ` Gerd Möllmann
2024-07-26 10:33 ` Gerd Möllmann
2024-07-26 10:55 ` Eli Zaretskii
2024-07-26 11:02 ` Gerd Möllmann
2024-07-26 19:09 ` Alan Third
2024-07-26 19:24 ` Gerd Möllmann
2024-07-26 19:36 ` Alan Third
2024-07-27 3:56 ` Gerd Möllmann
2024-07-27 6:37 ` Eli Zaretskii
2024-07-30 6:00 ` Gerd Möllmann
2024-07-31 3:22 ` Gerd Möllmann
2024-07-31 13:51 ` Eli Zaretskii
2024-07-26 9:56 ` Gerd Möllmann
2024-07-26 18:38 ` Alan Third
2024-07-26 19:02 ` Gerd Möllmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2r0gqm7jv.fsf@Pro.fritz.box \
--to=gerd.moellmann@gmail.com \
--cc=69525@debbugs.gnu.org \
--cc=alan@idiocy.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.