bug#45502: [PATCH] Prettier key bindings in NS menu entries

[Alan Third]

On Tue, Dec 29, 2020 at 06:34:20PM +0100, Mattias Engdegård wrote:
> 29 dec. 2020 kl. 16.50 skrev Alan Third <alan@idiocy.org>:
> 
> > As far as I'm aware GNUstep is able to display the bindings correctly
> > no matter how many characters they have, so we don't need the
> > work-around. And I'm hoping that we'll be able to get GNUstep menus
> > working again in the future.
> 
> All right, I've done what I think you meant and pushed to master;
> please tell me if I'm on the wrong track.

I've pushed a small change. I also set the alloc'd objects to
autorelease. We need to do that because when they're assigned to the
NSMenuItem it will retain them, and because we alloc'd them we already
have them retained once.

At least I hope that's right. For some reason I've found the
retain/release cycle really hard to understand, but I think I'm
getting there now.

> Here is a proof-of-concept patch for using fancy symbols instead of
> <right> etc.
>
> Not production quality because (1) it's obviously ugly code, (2) I'm
> unsure about the PgUp/PgDn/Home/End symbols and (3) it only works
> with modifiers if the patch in bug#45536 is applied (which of course
> I think it should), but at least it gives a feeling for whether it's
> a good thing to do or not.

I have no opinion on this, really. Although that is some ugly code! ;)

I have no ideas for how to improve it, though.

> There is also the question whether to follow the platform convention
> of always using upper case letters, with an explicit Shift modifier
> if necessary.

I think that might be confusing. It doesn't matter with most macOS
apps because they don't differentiate between shortcuts with upper and
lower case characters, but we do, and I feel as a seasoned Emacs user
I'd see C-A and think that was actually C-S-a when it might be C-a.

-- 
Alan Third