* bug#69525: 30.0.50; MacOS: New warnings on stderr
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
2024-03-05 5:31 ` Gerd Möllmann
2 siblings, 1 reply; 14+ messages in thread
From: Gerd Möllmann @ 2024-03-03 19:29 UTC (permalink / raw)
To: Alan Third; +Cc: 69525, Eli Zaretskii
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?
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#69525: 30.0.50; MacOS: New warnings on stderr
2024-03-03 19:29 ` Gerd Möllmann
@ 2024-03-04 9:12 ` Gerd Möllmann
0 siblings, 0 replies; 14+ messages in thread
From: Gerd Möllmann @ 2024-03-04 9:12 UTC (permalink / raw)
To: Alan Third; +Cc: 69525, Eli Zaretskii
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> Alan Third <alan@idiocy.org> writes:
>> 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.
I did revert the commit, but I now think, the freezes might not be
related to this all:
When trying to start Emacs after the revert, Emacs froze. I have a
desktop file that loads Emacs' frame.h. And Emacs freezes only if I load
eglot in my init file, and put eglot-ensure in c-mode-common-hook.
The other freezes I saw yesterday were also while doing C stuff, so they
could be related to using Eglot as well.
Maybe it's some change in Eglot, or, below that, in Emacs process code?
If someone knows if something changed in Eglot and/or Emacs in that
department, I'd be grateful.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#69525: 30.0.50; MacOS: New warnings on stderr
2024-03-03 18:06 ` Alan Third
2024-03-03 19:29 ` Gerd Möllmann
@ 2024-03-04 13:48 ` Gerd Möllmann
2024-03-04 14:43 ` Gerd Möllmann
2024-03-04 21:40 ` Alan Third
2024-03-05 5:31 ` Gerd Möllmann
2 siblings, 2 replies; 14+ messages in thread
From: Gerd Möllmann @ 2024-03-04 13:48 UTC (permalink / raw)
To: Alan Third; +Cc: 69525, Eli Zaretskii
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#69525: 30.0.50; MacOS: New warnings on stderr
2024-03-04 13:48 ` Gerd Möllmann
@ 2024-03-04 14:43 ` Gerd Möllmann
2024-03-04 21:40 ` Alan Third
1 sibling, 0 replies; 14+ messages in thread
From: Gerd Möllmann @ 2024-03-04 14:43 UTC (permalink / raw)
To: Alan Third; +Cc: 69525, Eli Zaretskii
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 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...
FYI, it's actually posframe. I've submitted an issue for that
https://github.com/tumashu/posframe/issues/136
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#69525: 30.0.50; MacOS: New warnings on stderr
2024-03-04 13:48 ` Gerd Möllmann
2024-03-04 14:43 ` Gerd Möllmann
@ 2024-03-04 21:40 ` Alan Third
2024-03-05 4:38 ` Gerd Möllmann
1 sibling, 1 reply; 14+ messages in thread
From: Alan Third @ 2024-03-04 21:40 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: 69525, Eli Zaretskii
On Mon, Mar 04, 2024 at 02:48:52PM +0100, Gerd Möllmann wrote:
> 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...
We should be able to create a frame without the system throwing out
errors, though. I wonder if this is something we're doing (like
makeKeyAndOrderFront being called on the new frame and it not checking
canBecomeKeyWindow) or if there's some other step we need to take to
prevent this. I'm fairly sure that I've never seen these warnings so
presumably they're new since 10.14.
--
Alan Third
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#69525: 30.0.50; MacOS: New warnings on stderr
2024-03-04 21:40 ` Alan Third
@ 2024-03-05 4:38 ` Gerd Möllmann
2024-03-05 12:59 ` Alan Third
0 siblings, 1 reply; 14+ messages in thread
From: Gerd Möllmann @ 2024-03-05 4:38 UTC (permalink / raw)
To: Alan Third; +Cc: 69525, Eli Zaretskii
Alan Third <alan@idiocy.org> writes:
>> 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...
>
> We should be able to create a frame without the system throwing out
> errors, though.
True.
> I wonder if this is something we're doing (like makeKeyAndOrderFront
> being called on the new frame and it not checking canBecomeKeyWindow)
> or if there's some other step we need to take to prevent this. I'm
> fairly sure that I've never seen these warnings so presumably they're
> new since 10.14.
You are thinking of this in nsterm.m?
- (void)makeKeyAndOrderFront:(id)sender
{
NSTRACE ("[EmacsWindow makeKeyAndOrderFront:]");
if ([self parentWindow])
{
[self orderFront:sender];
[self makeKeyWindow];
}
else
[super makeKeyAndOrderFront:sender];
}
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#69525: 30.0.50; MacOS: New warnings on stderr
2024-03-05 4:38 ` Gerd Möllmann
@ 2024-03-05 12:59 ` Alan Third
2024-03-05 14:31 ` Gerd Möllmann
0 siblings, 1 reply; 14+ messages in thread
From: Alan Third @ 2024-03-05 12:59 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: 69525, Eli Zaretskii
On Tue, Mar 05, 2024 at 05:38:26AM +0100, Gerd Möllmann wrote:
> Alan Third <alan@idiocy.org> writes:
>
> > I wonder if this is something we're doing (like makeKeyAndOrderFront
> > being called on the new frame and it not checking canBecomeKeyWindow)
> > or if there's some other step we need to take to prevent this. I'm
> > fairly sure that I've never seen these warnings so presumably they're
> > new since 10.14.
>
> You are thinking of this in nsterm.m?
>
> - (void)makeKeyAndOrderFront:(id)sender
> {
> NSTRACE ("[EmacsWindow makeKeyAndOrderFront:]");
>
> if ([self parentWindow])
> {
> [self orderFront:sender];
> [self makeKeyWindow];
> }
> else
> [super makeKeyAndOrderFront:sender];
> }
Yes. I think it's the only place we actually call makeKeyWindow
ourselves, so perhaps it should have a test. Could be worth it just to
see if it makes the messages go away.
So I guess just something like
if ([self canBecomeKeyWindow])
[self makeKeyWindow];
--
Alan Third
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#69525: 30.0.50; MacOS: New warnings on stderr
2024-03-05 12:59 ` Alan Third
@ 2024-03-05 14:31 ` Gerd Möllmann
0 siblings, 0 replies; 14+ messages in thread
From: Gerd Möllmann @ 2024-03-05 14:31 UTC (permalink / raw)
To: Alan Third; +Cc: 69525, Eli Zaretskii
Alan Third <alan@idiocy.org> writes:
> On Tue, Mar 05, 2024 at 05:38:26AM +0100, Gerd Möllmann wrote:
>> Alan Third <alan@idiocy.org> writes:
>>
>> > I wonder if this is something we're doing (like makeKeyAndOrderFront
>> > being called on the new frame and it not checking canBecomeKeyWindow)
>> > or if there's some other step we need to take to prevent this. I'm
>> > fairly sure that I've never seen these warnings so presumably they're
>> > new since 10.14.
>>
>> You are thinking of this in nsterm.m?
>>
>> - (void)makeKeyAndOrderFront:(id)sender
>> {
>> NSTRACE ("[EmacsWindow makeKeyAndOrderFront:]");
>>
>> if ([self parentWindow])
>> {
>> [self orderFront:sender];
>> [self makeKeyWindow];
>> }
>> else
>> [super makeKeyAndOrderFront:sender];
>> }
>
> Yes. I think it's the only place we actually call makeKeyWindow
> ourselves, so perhaps it should have a test. Could be worth it just to
> see if it makes the messages go away.
>
> So I guess just something like
>
> if ([self canBecomeKeyWindow])
> [self makeKeyWindow];
Alas, that didn't work. I replaced the whole method body with the 2
lines, but then the Emacs frame wouldn't show up on start. There are
some calls to makeKeyWindow in other .m files, BTW.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#69525: 30.0.50; MacOS: New warnings on stderr
2024-03-03 18:06 ` Alan Third
2024-03-03 19:29 ` Gerd Möllmann
2024-03-04 13:48 ` Gerd Möllmann
@ 2024-03-05 5:31 ` Gerd Möllmann
2 siblings, 0 replies; 14+ messages in thread
From: Gerd Möllmann @ 2024-03-05 5:31 UTC (permalink / raw)
To: Alan Third; +Cc: 69525, Eli Zaretskii
Alan Third <alan@idiocy.org> writes:
>> >>> 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.
I've now compared Apple's docss at
https://developer.apple.com/documentation/appkit/nstextinputclient
with what's in nsterm.m, and I think it's indeed different. (Add usual
disclaimer that I know neither ObjC nor NS.)
Apple:
func setMarkedText(Any, selectedRange: NSRange, replacementRange: NSRange)
Replaces a specified range in the receiver’s text storage with the given string and sets the selection.
Required
nsterm.m
- (void)setMarkedText: (id)aString selectedRange: (NSRange)selRange
func validAttributesForMarkedText() -> [NSAttributedString.Key]
Returns an array of attribute names recognized by the receiver.
Required
- (NSArray *)validAttributesForMarkedText
func attributedSubstring(forProposedRange: NSRange, actualRange: NSRangePointer?) -> NSAttributedString?
- (NSAttributedString *)attributedSubstringFromRange: (NSRange)theRange
func insertText(Any, replacementRange: NSRange)
Inserts the given string into the receiver, replacing the specified content.
Required
- (void)insertText: (id)aString
Stopped here.
^ permalink raw reply [flat|nested] 14+ messages in thread