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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 69525 in the body.
You can then email your comments to 69525 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; MacOS: New warnings on stderr
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].
2024-03-03 17:10:35.434255+0100 emacs[12805:61381] [CursorUI] -[TUINSCursorUIController activate:]: EmacsView doesn't conform to NSTextInputClient protocol.
2024-03-03 17:10:37.073109+0100 emacs[12805:61381] [Window] Warning: -[NSWindow makeKeyWindow] called on EmacsWindow 0x7f7d90a34030 which returned NO from -[NSWindow canBecomeKeyWindow].
2024-03-03 17:13:19.141805+0100 emacs[12805:61381] [CursorUI] -[TUINSCursorUIController activate:]: EmacsView doesn't conform to NSTextInputClient protocol.

In GNU Emacs 30.0.50 (build 1, x86_64-apple-darwin23.3.0, NS
 appkit-2487.40 Version 14.3.1 (Build 23D60)) of 2024-03-01 built on
 Pro.fritz.box
Repository revision: 862dfef88d8e62d12bac3ca2e44e035a2ff5b298
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.3.1

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

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

> 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].
> 2024-03-03 17:10:35.434255+0100 emacs[12805:61381] [CursorUI] -[TUINSCursorUIController activate:]: EmacsView doesn't conform to NSTextInputClient protocol.
> 2024-03-03 17:10:37.073109+0100 emacs[12805:61381] [Window] Warning: -[NSWindow makeKeyWindow] called on EmacsWindow 0x7f7d90a34030 which returned NO from -[NSWindow canBecomeKeyWindow].
> 2024-03-03 17:13:19.141805+0100 emacs[12805:61381] [CursorUI] -[TUINSCursorUIController activate:]: EmacsView doesn't conform to NSTextInputClient protocol.

Alan, any ideas or suggestions?

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

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

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].
>> 2024-03-03 17:10:35.434255+0100 emacs[12805:61381] [CursorUI] -[TUINSCursorUIController activate:]: EmacsView doesn't conform to NSTextInputClient protocol.
>> 2024-03-03 17:10:37.073109+0100 emacs[12805:61381] [Window] Warning: -[NSWindow makeKeyWindow] called on EmacsWindow 0x7f7d90a34030 which returned NO from -[NSWindow canBecomeKeyWindow].
>> 2024-03-03 17:13:19.141805+0100 emacs[12805:61381] [CursorUI] -[TUINSCursorUIController activate:]: EmacsView doesn't conform to NSTextInputClient protocol.
>
> 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.

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

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

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].
>>> 2024-03-03 17:10:35.434255+0100 emacs[12805:61381] [CursorUI] -[TUINSCursorUIController activate:]: EmacsView doesn't conform to NSTextInputClient protocol.
>>> 2024-03-03 17:10:37.073109+0100 emacs[12805:61381] [Window] Warning: -[NSWindow makeKeyWindow] called on EmacsWindow 0x7f7d90a34030 which returned NO from -[NSWindow canBecomeKeyWindow].
>>> 2024-03-03 17:13:19.141805+0100 emacs[12805:61381] [CursorUI] -[TUINSCursorUIController activate:]: EmacsView doesn't conform to NSTextInputClient protocol.
>>
>> 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.

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

From: Alan Third <alan <at> idiocy.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
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, 3 Mar 2024 18:06:34 +0000

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?

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

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

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.

Message #23 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: Mon, 04 Mar 2024 10:12:24 +0100

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

>> Alan Third <alan <at> 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.

Message #26 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: 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.

Message #29 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: Mon, 04 Mar 2024 15:43:14 +0100

Gerd Möllmann <gerd.moellmann <at> 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

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

From: Alan Third <alan <at> idiocy.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
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: Mon, 4 Mar 2024 21:40:06 +0000

On Mon, Mar 04, 2024 at 02:48:52PM +0100, Gerd Möllmann wrote:
> 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...

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

Message #35 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: Tue, 05 Mar 2024 05:38:26 +0100

Alan Third <alan <at> 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];
  }

Message #38 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: Tue, 05 Mar 2024 06:31:16 +0100

Alan Third <alan <at> 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.

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

From: Alan Third <alan <at> idiocy.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
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: Tue, 5 Mar 2024 12:59:30 +0000

On Tue, Mar 05, 2024 at 05:38:26AM +0100, Gerd Möllmann wrote:
> Alan Third <alan <at> 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

Message #44 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: Tue, 05 Mar 2024 15:31:47 +0100

Alan Third <alan <at> idiocy.org> writes:

> On Tue, Mar 05, 2024 at 05:38:26AM +0100, Gerd Möllmann wrote:
>> Alan Third <alan <at> 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.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: 69525 <at> debbugs.gnu.org
Cc: Alan Third <alan <at> idiocy.org>
Subject: Re: bug#69525: 30.0.50; MacOS: New warnings on stderr
Date: Fri, 26 Jul 2024 11:56:21 +0200

[Message part 1 (text/plain, inline)]

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

> 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].
> 2024-03-03 17:10:35.434255+0100 emacs[12805:61381] [CursorUI] -[TUINSCursorUIController activate:]: EmacsView doesn't conform to NSTextInputClient protocol.
> 2024-03-03 17:10:37.073109+0100 emacs[12805:61381] [Window] Warning: -[NSWindow makeKeyWindow] called on EmacsWindow 0x7f7d90a34030 which returned NO from -[NSWindow canBecomeKeyWindow].
> 2024-03-03 17:13:19.141805+0100 emacs[12805:61381] [CursorUI] -[TUINSCursorUIController activate:]: EmacsView doesn't conform to NSTextInputClient protocol.
>
> In GNU Emacs 30.0.50 (build 1, x86_64-apple-darwin23.3.0, NS
>  appkit-2487.40 Version 14.3.1 (Build 23D60)) of 2024-03-01 built on
>  Pro.fritz.box
> Repository revision: 862dfef88d8e62d12bac3ca2e44e035a2ff5b298
> Repository branch: master
> Windowing system distributor 'Apple', version 10.3.2487
> System Description:  macOS 14.3.1

The attached patch fixes this for me, and seems logical.

[0001-NS-prevent-makeKeyWindow-warnings-bug-69525.patch (text/x-patch, attachment)]

Message #50 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: Fri, 26 Jul 2024 12:33:24 +0200

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

> Alan Third <alan <at> 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.

Apple's documentation says

  Important
  
  NSTextInput protocol is slated for deprecation. Please use the
  NSTextInputClient protocol instead.

I guess that's the reason for the warning, and we should switch to using
NSTextInputClient.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 69525 <at> debbugs.gnu.org, alan <at> idiocy.org
Subject: Re: bug#69525: 30.0.50; MacOS: New warnings on stderr
Date: Fri, 26 Jul 2024 13:55:17 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: 69525 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>
> Date: Fri, 26 Jul 2024 12:33:24 +0200
> 
> Apple's documentation says
> 
>   Important
>   
>   NSTextInput protocol is slated for deprecation. Please use the
>   NSTextInputClient protocol instead.
> 
> I guess that's the reason for the warning, and we should switch to using
> NSTextInputClient.

Does this mean the patch you just posted is no longer relevant or
desirable?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69525 <at> debbugs.gnu.org, alan <at> idiocy.org
Subject: Re: bug#69525: 30.0.50; MacOS: New warnings on stderr
Date: Fri, 26 Jul 2024 13:02:04 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: 69525 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>
>> Date: Fri, 26 Jul 2024 12:33:24 +0200
>> 
>> Apple's documentation says
>> 
>>   Important
>>   
>>   NSTextInput protocol is slated for deprecation. Please use the
>>   NSTextInputClient protocol instead.
>> 
>> I guess that's the reason for the warning, and we should switch to using
>> NSTextInputClient.
>
> Does this mean the patch you just posted is no longer relevant or
> desirable?

No, there are 2 kinds of warnings, with two different reasons.
The patch I sent is for the warning regarding makeKeyWindow.

This mail concerns

  2024-07-26 12:38:12.984973+0200 emacs[61974:18565128] [CursorUI]
  -[TUINSCursorUIController activate:]: EmacsView doesn't conform to
  NSTextInputClient protocol.

And it looks like we have to switch to using NSTextInputClient at some
point instead of using NSTextInput.

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

From: Alan Third <alan <at> idiocy.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 69525 <at> debbugs.gnu.org
Subject: Re: bug#69525: 30.0.50; MacOS: New warnings on stderr
Date: Fri, 26 Jul 2024 19:38:45 +0100

On Fri, Jul 26, 2024 at 11:56:21AM +0200, Gerd Möllmann wrote:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> 
> > 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].
> > 2024-03-03 17:10:35.434255+0100 emacs[12805:61381] [CursorUI] -[TUINSCursorUIController activate:]: EmacsView doesn't conform to NSTextInputClient protocol.
> > 2024-03-03 17:10:37.073109+0100 emacs[12805:61381] [Window] Warning: -[NSWindow makeKeyWindow] called on EmacsWindow 0x7f7d90a34030 which returned NO from -[NSWindow canBecomeKeyWindow].
> > 2024-03-03 17:13:19.141805+0100 emacs[12805:61381] [CursorUI] -[TUINSCursorUIController activate:]: EmacsView doesn't conform to NSTextInputClient protocol.
> >
> > In GNU Emacs 30.0.50 (build 1, x86_64-apple-darwin23.3.0, NS
> >  appkit-2487.40 Version 14.3.1 (Build 23D60)) of 2024-03-01 built on
> >  Pro.fritz.box
> > Repository revision: 862dfef88d8e62d12bac3ca2e44e035a2ff5b298
> > Repository branch: master
> > Windowing system distributor 'Apple', version 10.3.2487
> > System Description:  macOS 14.3.1
> 
> The attached patch fixes this for me, and seems logical.

LGTM
-- 
Alan Third

Message #62 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
Subject: Re: bug#69525: 30.0.50; MacOS: New warnings on stderr
Date: Fri, 26 Jul 2024 21:02:25 +0200

Alan Third <alan <at> idiocy.org> writes:

> LGTM

Thanks Alan, I've pushed that to emacs-30.

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

From: Alan Third <alan <at> idiocy.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
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: Fri, 26 Jul 2024 20:09:35 +0100

On Fri, Jul 26, 2024 at 12:33:24PM +0200, Gerd Möllmann wrote:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> 
> > Alan Third <alan <at> 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.

FYI, up at the top right of the Apple docs you can change from Swift
to Objective C, which will probably make comparisons easier.

> Apple's documentation says
> 
>   Important
>   
>   NSTextInput protocol is slated for deprecation. Please use the
>   NSTextInputClient protocol instead.
> 
> I guess that's the reason for the warning, and we should switch to using
> NSTextInputClient.

Looks that way. AFAICT NSTextInputClient should be available on all
versions of macOS we support and also in GNUstep, although it can be
hard to tell which versions of GNUstep support what.

Some of these functions are just used for normal input, but many of
them are used exclusively for macOS input methods.
-- 
Alan Third

Message #68 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: Fri, 26 Jul 2024 21:24:36 +0200

Alan Third <alan <at> idiocy.org> writes:

>> >   - (void)insertText: (id)aString
>> >
>> > Stopped here.
>
> FYI, up at the top right of the Apple docs you can change from Swift
> to Objective C, which will probably make comparisons easier.

Ah thanks, I didn't see that!

>
>> Apple's documentation says
>> 
>>   Important
>>   
>>   NSTextInput protocol is slated for deprecation. Please use the
>>   NSTextInputClient protocol instead.
>> 
>> I guess that's the reason for the warning, and we should switch to using
>> NSTextInputClient.
>
> Looks that way. AFAICT NSTextInputClient should be available on all
> versions of macOS we support and also in GNUstep, although it can be
> hard to tell which versions of GNUstep support what.
>
> Some of these functions are just used for normal input, but many of
> them are used exclusively for macOS input methods.

I find Apple's documentation of the protocol pretty bad, to say the
least, and examples seem to be lacking completely. Don't know if I can
pull that off.

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

From: Alan Third <alan <at> idiocy.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
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: Fri, 26 Jul 2024 20:36:57 +0100

On Fri, Jul 26, 2024 at 09:24:36PM +0200, Gerd Möllmann wrote:
> Alan Third <alan <at> idiocy.org> writes:
> 
> >
> >> Apple's documentation says
> >> 
> >>   Important
> >>   
> >>   NSTextInput protocol is slated for deprecation. Please use the
> >>   NSTextInputClient protocol instead.
> >> 
> >> I guess that's the reason for the warning, and we should switch to using
> >> NSTextInputClient.
> >
> > Looks that way. AFAICT NSTextInputClient should be available on all
> > versions of macOS we support and also in GNUstep, although it can be
> > hard to tell which versions of GNUstep support what.
> >
> > Some of these functions are just used for normal input, but many of
> > them are used exclusively for macOS input methods.
> 
> I find Apple's documentation of the protocol pretty bad, to say the
> least, and examples seem to be lacking completely. Don't know if I can
> pull that off.

Yeah, I was trying to work out what the actual differences are between
them and I suspect they're fairly minimal, but I don't know how we
should handle insertText:replacementRange: vs the current insertText:,
for example.

The new one takes a range and the old one doesn't. IMO it's none of
the window system's business where we insert the text, so do we just
ignore it? That might cause issues if we're dealing with the language
input stuff, so we might need to fiddle with that a bit (it was mostly
contributed by someone who actually used it).

I would agree that Apple's documentation is abysmal. AFAICT most new
features are exclusively documented in WWDC talks, so if you're not
immersed in the Apple eco-system it can be very hard to keep track of
what's changed. I assume that's some sort of marketing ploy.
-- 
Alan Third

Message #74 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: Sat, 27 Jul 2024 05:56:30 +0200

Alan Third <alan <at> idiocy.org> writes:

>> I find Apple's documentation of the protocol pretty bad, to say the
>> least, and examples seem to be lacking completely. Don't know if I can
>> pull that off.
>
> Yeah, I was trying to work out what the actual differences are between
> them and I suspect they're fairly minimal, but I don't know how we
> should handle insertText:replacementRange: vs the current insertText:,
> for example.
>
> The new one takes a range and the old one doesn't. IMO it's none of
> the window system's business where we insert the text, so do we just
> ignore it? That might cause issues if we're dealing with the language
> input stuff, so we might need to fiddle with that a bit (it was mostly
> contributed by someone who actually used it).
>
> I would agree that Apple's documentation is abysmal. AFAICT most new
> features are exclusively documented in WWDC talks, so if you're not
> immersed in the Apple eco-system it can be very hard to keep track of
> what's changed. I assume that's some sort of marketing ploy.

Yeah, could be. Although I wonder what advantage they expect from making
such stuff effectively a secret :-/.

BTW, I found a github repo with lots of Cocoa samples which might be of
help at some point. This one is about NSTextInputClient, it seems:

  https://github.com/HelmutJ/CocoaSampleCode/tree/master/TextInputView

I've read it, but without any further background I find it hard to
understand. Maybe it's helpful for you, though. It does do something
with these ranges, for example.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 69525 <at> debbugs.gnu.org, alan <at> idiocy.org
Subject: Re: bug#69525: 30.0.50; MacOS: New warnings on stderr
Date: Sat, 27 Jul 2024 09:37:01 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: 69525 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>
> Date: Sat, 27 Jul 2024 05:56:30 +0200
> 
> Alan Third <alan <at> idiocy.org> writes:
> 
> > I would agree that Apple's documentation is abysmal. AFAICT most new
> > features are exclusively documented in WWDC talks, so if you're not
> > immersed in the Apple eco-system it can be very hard to keep track of
> > what's changed. I assume that's some sort of marketing ploy.
> 
> Yeah, could be. Although I wonder what advantage they expect from making
> such stuff effectively a secret :-/.

Companies that develop proprietary software for macOS can probably
fund courses for their employees, or buy auxiliary documentation that
is not available for free, or ask Apple questions and get answers,
something that could be available only for those who have contracts
with Apple.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69525 <at> debbugs.gnu.org, alan <at> idiocy.org
Subject: Re: bug#69525: 30.0.50; MacOS: New warnings on stderr
Date: Tue, 30 Jul 2024 08:00:35 +0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: 69525 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>
>> Date: Sat, 27 Jul 2024 05:56:30 +0200
>> 
>> Alan Third <alan <at> idiocy.org> writes:
>> 
>> > I would agree that Apple's documentation is abysmal. AFAICT most new
>> > features are exclusively documented in WWDC talks, so if you're not
>> > immersed in the Apple eco-system it can be very hard to keep track of
>> > what's changed. I assume that's some sort of marketing ploy.
>> 
>> Yeah, could be. Although I wonder what advantage they expect from making
>> such stuff effectively a secret :-/.
>
> Companies that develop proprietary software for macOS can probably
> fund courses for their employees, or buy auxiliary documentation that
> is not available for free, or ask Apple questions and get answers,
> something that could be available only for those who have contracts
> with Apple.

Yeah, maybe :-/.

Meanwhile, I think I pulled this off anyway by studying and mimicking
what others did. At least it works for me on macOS 14.5 just like the
old code did, at least for entering accented characters, which is the
only thing I know how to use.

I'll push that to master, if nobody objects.

[0001-NS-Let-EmacsView-implement-NSTextInputClient.patch (text/x-patch, attachment)]

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69525 <at> debbugs.gnu.org, alan <at> idiocy.org
Subject: Re: bug#69525: 30.0.50; MacOS: New warnings on stderr
Date: Wed, 31 Jul 2024 05:22:10 +0200

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

> I'll push that to master, if nobody objects.

Pushed to emacs-30 instead, because it looks safe. Closing.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 69525 <at> debbugs.gnu.org, alan <at> idiocy.org
Subject: Re: bug#69525: 30.0.50; MacOS: New warnings on stderr
Date: Wed, 31 Jul 2024 16:51:40 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: 69525 <at> debbugs.gnu.org,  alan <at> idiocy.org
> Date: Wed, 31 Jul 2024 05:22:10 +0200
> 
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> 
> > I'll push that to master, if nobody objects.
> 
> Pushed to emacs-30 instead, because it looks safe. Closing.

Famous last words.  You should have installed on master.

Previous Next

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