bug#81610: 30.2; [PATCH] NS; NSRangeException when enabling tool-bar-mode

On Wed, Aug 12, 2026 at 06:01:18PM +0300, Eli Zaretskii wrote:
> > Cc: [email protected]
> > Date: Wed, 12 Aug 2026 16:54:06 +0300
> > From: Yavor Doganov <[email protected]>
> > 
> > If I customize the tool-bar-mode variable to nil then the toolbar is
> > not displayed, as expected.  However, if I enable it explicitly with
> > the interactive command, an exception is thrown: a dialog "Critical
> > Error in emacs" appears containing "NSRangeException: Index 0 is out
> > of range 0 (in 'objectAtIndex:')".  Emacs then aborts.
> > 
> > Steps to reproduce:
> > 
> >   1. emacs -Q --eval "(tool-bar-mode -1)"
> >   2. M-x tool-bar-mode RET
> > 
> > Backtrace and proposed patch below based on the master branch.
> > 
<snip>
> > Notice that in GDB frames 2 and 3 there are two distinct EmacsToolbar
> > instances for a single Emacs frame.  The one from GDB frame 2,
> > 0x555557a87500, is a "parasite" object: it is initialized at frame
> > creation and toolbar items are never insterted in it.
> > 
> > GNUstep's NSToolbar implementation of -removeItemAtIndex: (called from
> > EmacsToolbar -clearAll, nsmenu.m:1310) calls the private method
> > -_removeItemAtIndex:broadcast: which calls itself recursively,
> > dispatching the method call to all instances of the same class with
> > identical identifiers (see the TRANSMIT macro definition in
> > gnustep-gui/Source/NSToolbar.m:1205).  The goal here is to update the
> > toolbars of the app's other windows ("frames" in Emacs terminology) if
> > the identifiers match.
> > 
> > Because this first EmacsToolbar instance doesn't have any toolbar
> > items, an exception occurs.
> 
> Alan, any comments to the patch?  Because it's definitely
> macOS-specific.

This doesn't look right to me, but I don't have a GNUstep environment
to test it in and, frankly, I can't remember how toolbars work, if I
ever knew.
-- 
Alan Third