GNU bug report logs - #45502
[PATCH] Prettier key bindings in NS menu entries

Previous Next

Package: emacs;

Reported by: Mattias Engdegård <mattiase <at> acm.org>

Date: Mon, 28 Dec 2020 14:24:02 UTC

Severity: normal

Tags: patch

Done: Mattias Engdegård <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Mon, 28 Dec 2020 14:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mattias Engdegård <mattiase <at> acm.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 28 Dec 2020 14:24:02 GMT) Full text and rfc822 format available.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Prettier key bindings in NS menu entries
Date: Mon, 28 Dec 2020 15:23:25 +0100
[Message part 1 (text/plain, inline)]
The NS port shows key bindings in a rather cluttered way, with the key in brackets directly after the menu entry. The Mac port of Emacs is much neater with the bindings all aligned at a common tab position. We could do the same, but having done some experiments I actually prefer a right-alignment of the keys. Proof-of-concept patch attached.

The alignment is made by padding with spaces, and then with hair spaces for extra precision; the result is not perfect but probably better than what we have now. If I get some time, I might do an experiment with more precise formatting.

[right-justify-keys.diff (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Mon, 28 Dec 2020 18:37:01 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 45502 <at> debbugs.gnu.org
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Mon, 28 Dec 2020 18:36:05 +0000
On Mon, Dec 28, 2020 at 03:23:25PM +0100, Mattias Engdegård wrote:
> The NS port shows key bindings in a rather cluttered way, with the
> key in brackets directly after the menu entry. The Mac port of Emacs
> is much neater with the bindings all aligned at a common tab
> position. We could do the same, but having done some experiments I
> actually prefer a right-alignment of the keys. Proof-of-concept
> patch attached.
> 
> The alignment is made by padding with spaces, and then with hair
> spaces for extra precision; the result is not perfect but probably
> better than what we have now. If I get some time, I might do an
> experiment with more precise formatting.
> 


> > I'd wondered about using NSAttributedString and NSParagraphStyle to
> > set a tab stop at a specific pixel point, that should allow perfect
> > alignment, or, and this is a bit hackier, display the binding in a
> > monospace font. Then you could use (variable space font) spaces and
> > tabs to line up the start of the binding text, then use (monospace
> > font) spaces to align the bindings. That's maybe a bit too much work,
> > though, and I'm not at all knowledgeable about how NSAttributedStrings
> > actually work, so maybe it's impossible.
> 
> It didn't look obvious how to do it, but I could use some help.

I'm not sure either, but I guess the tabstop thing would look
something like:

NSMutableParagraphStyle *p = [NSMutableParagraphStyle
                               defaultParagraphStyle];
NSArray *tabstops = [NSArray withObject:[[[NSTextTab alloc]
                        initWithTextAlignment:NSTextAlignmentRight
                                     location:50 // This is probably in points.
                                      options:nil];
[p setTabStops:tabstops];

NSAttributedString *s = [[NSAttributedString alloc]
                          initWithString:yourString
                              attributes:someDictionaryObjectIncludingTheParagraphStyle];

[releaseAllTheAllocedObjects];

I can never remember how to make dictionaries, so I'll leave that to
you to work out. ;)

Hopefully then all you have to do is set the string as the title and it will
be drawn with the correct tabstop. Maybe NSMenuItems are special and
it won't work, though.
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Mon, 28 Dec 2020 22:47:01 GMT) Full text and rfc822 format available.

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 45502 <at> debbugs.gnu.org
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Mon, 28 Dec 2020 23:46:36 +0100
Mattias Engdegård <mattiase <at> acm.org> writes:

> The NS port shows key bindings in a rather cluttered way, with the key
> in brackets directly after the menu entry. The Mac port of Emacs is
> much neater with the bindings all aligned at a common tab position. We
> could do the same, but having done some experiments I actually prefer
> a right-alignment of the keys. Proof-of-concept patch attached.
>
> The alignment is made by padding with spaces, and then with hair
> spaces for extra precision; the result is not perfect but probably
> better than what we have now. If I get some time, I might do an
> experiment with more precise formatting.

Thanks for the patch! It crashed Emacs when I tried to open the Gnus
menu bar (the Gnus menu bar is an extreme case with lots of bindings).

I'm not sure if left-alignment or right-alignment would be better.  To
improve visuals, Apple seems to align with respect to the ⌘ symbol, but
that doesn't fit Emacs well because there's no single modifier that is
used in almost every keybinding (some use Control, some Meta).  Also,
it's not uncommon in Emacs to have keybindings that are a couple of
keymaps deep.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Tue, 29 Dec 2020 12:06:02 GMT) Full text and rfc822 format available.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 45502 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Tue, 29 Dec 2020 13:02:21 +0100
[Message part 1 (text/plain, inline)]
28 dec. 2020 kl. 19.36 skrev Alan Third <alan <at> idiocy.org>:

> I'm not sure either, but I guess the tabstop thing would look
> something like: [...]

Actually seems to work! (In your place I would feign a complete lack of surprise.)
Resulting patch attached.

28 dec. 2020 kl. 23.46 skrev Daniel Martín <mardani29 <at> yahoo.es>:

> Thanks for the patch! It crashed Emacs when I tried to open the Gnus
> menu bar (the Gnus menu bar is an extreme case with lots of bindings).

Confirmed, but that is unrelated to my patch. Alan, will you have a look?

> I'm not sure if left-alignment or right-alignment would be better.  To
> improve visuals, Apple seems to align with respect to the ⌘ symbol, but
> that doesn't fit Emacs well because there's no single modifier that is
> used in almost every keybinding (some use Control, some Meta).  Also,
> it's not uncommon in Emacs to have keybindings that are a couple of
> keymaps deep.

Right; it's easy to use either left or right alignment for the bindings. (I think we all agree that they should be kept in a separate column to the right of the menu strings in either case.) I'm going to experiment with translating modifiers and keys to the standard symbols. Not sure how to deal with modifiers that are unavailable, such as s-k when no Super modifier is available.

It might be a good idea to normalise how key bindings are displayed on all platforms to some extent. For example, <C-return> is better written C-<return> or C-RET, <M-backspace> is better as M-<backspace> or M-DEL (although not necessarily exactly the same thing, it's a bit muddy).

Of course <> are terrible as angle brackets; we typically want ‹› or ⟨⟩ depending on context and purpose.

[0001-Right-justify-keys-in-NS-menu-entries-bug-45502.patch (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Tue, 29 Dec 2020 13:55:02 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 45502 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Tue, 29 Dec 2020 13:53:55 +0000
On Tue, Dec 29, 2020 at 01:02:21PM +0100, Mattias Engdegård wrote:
> 28 dec. 2020 kl. 19.36 skrev Alan Third <alan <at> idiocy.org>:
> 
> > I'm not sure either, but I guess the tabstop thing would look
> > something like: [...]
> 
> Actually seems to work! (In your place I would feign a complete lack
> of surprise.)

No feigning required. 😉

> Resulting patch attached.

Looks good. As I understand it GNUstep doesn't need this fix, so
please make it Cocoa only.

> 28 dec. 2020 kl. 23.46 skrev Daniel Martín <mardani29 <at> yahoo.es>:
> 
> > Thanks for the patch! It crashed Emacs when I tried to open the Gnus
> > menu bar (the Gnus menu bar is an extreme case with lots of bindings).
> 
> Confirmed, but that is unrelated to my patch. Alan, will you have a look?

There was a work-around for some problem related to waiting_for_input
in the old menu code that was lost when I copied the code from
xmenu.c, so I've put it back in and pushed to master. It looks like it
fixes the crash here.

> > I'm not sure if left-alignment or right-alignment would be better.  To
> > improve visuals, Apple seems to align with respect to the ⌘ symbol, but
> > that doesn't fit Emacs well because there's no single modifier that is
> > used in almost every keybinding (some use Control, some Meta).  Also,
> > it's not uncommon in Emacs to have keybindings that are a couple of
> > keymaps deep.
> 
> Right; it's easy to use either left or right alignment for the
> bindings. (I think we all agree that they should be kept in a
> separate column to the right of the menu strings in either case.)
> I'm going to experiment with translating modifiers and keys to the
> standard symbols. Not sure how to deal with modifiers that are
> unavailable, such as s-k when no Super modifier is available.

There's also the problem that we allow setting the left and right
modifiers separately, so option or command may not match both keys.

-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Tue, 29 Dec 2020 14:42:02 GMT) Full text and rfc822 format available.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 45502 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Tue, 29 Dec 2020 15:41:03 +0100
29 dec. 2020 kl. 14.53 skrev Alan Third <alan <at> idiocy.org>:

> Looks good. As I understand it GNUstep doesn't need this fix, so
> please make it Cocoa only.

Will do, but what do you mean by not needing it -- does it do any harm, given that GNUstep menus do not appear to be working anyway? I have no GNUstep system to try it on so I don't know if it will even build.

> There was a work-around for some problem related to waiting_for_input
> in the old menu code that was lost when I copied the code from
> xmenu.c, so I've put it back in and pushed to master. It looks like it
> fixes the crash here.

Thank you, that did it.

> There's also the problem that we allow setting the left and right
> modifiers separately, so option or command may not match both keys.

That's true. Maybe a hybrid like M-↓ or C-⌫ is still fine though since the symbols are very recognisable -- I'll give it a go.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Tue, 29 Dec 2020 15:51:01 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 45502 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Tue, 29 Dec 2020 15:50:34 +0000
On Tue, Dec 29, 2020 at 03:41:03PM +0100, Mattias Engdegård wrote:
> 29 dec. 2020 kl. 14.53 skrev Alan Third <alan <at> idiocy.org>:
> 
> > Looks good. As I understand it GNUstep doesn't need this fix, so
> > please make it Cocoa only.
> 
> Will do, but what do you mean by not needing it -- does it do any
> harm, given that GNUstep menus do not appear to be working anyway? I
> have no GNUstep system to try it on so I don't know if it will even
> build.

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.

I think the problem is something to do with drawing the frame rather
than a problem with building the menus. But I could be wrong.

> > There's also the problem that we allow setting the left and right
> > modifiers separately, so option or command may not match both keys.
> 
> That's true. Maybe a hybrid like M-↓ or C-⌫ is still fine though
> since the symbols are very recognisable -- I'll give it a go.

Yes, I think so.
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Tue, 29 Dec 2020 17:35:02 GMT) Full text and rfc822 format available.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 45502 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Tue, 29 Dec 2020 18:34:20 +0100
[Message part 1 (text/plain, inline)]
29 dec. 2020 kl. 16.50 skrev Alan Third <alan <at> 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.

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.

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

[key-symbols.diff (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Tue, 29 Dec 2020 21:25:01 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 45502 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Tue, 29 Dec 2020 21:24:37 +0000
On Tue, Dec 29, 2020 at 06:34:20PM +0100, Mattias Engdegård wrote:
> 29 dec. 2020 kl. 16.50 skrev Alan Third <alan <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Tue, 29 Dec 2020 22:55:02 GMT) Full text and rfc822 format available.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 45502 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Tue, 29 Dec 2020 23:53:59 +0100
29 dec. 2020 kl. 22.24 skrev Alan Third <alan <at> idiocy.org>:

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

Thanks! Is this the standard way of doing it? The objects that you marked autorelease (tab and pstyle) are only used for the extent of that method; I take it you prefer autorelease to sending them 'release' at the end of the method?

Presumably 'atitle' should be sent autorelease (or release) as well?

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

Oh yes, it should at least be table-driven in some way. 

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

Agreed. If we were to follow the macOS conventions fully then it would make sense to use ⌘K for M-k (if Command is Meta), but otherwise it's more likely to be confusing.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Tue, 29 Dec 2020 23:50:02 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 45502 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Tue, 29 Dec 2020 23:49:02 +0000
On Tue, Dec 29, 2020 at 11:53:59PM +0100, Mattias Engdegård wrote:
> 29 dec. 2020 kl. 22.24 skrev Alan Third <alan <at> idiocy.org>:
> 
> > 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.
> 
> Thanks! Is this the standard way of doing it? The objects that you
> marked autorelease (tab and pstyle) are only used for the extent of
> that method; I take it you prefer autorelease to sending them
> 'release' at the end of the method?

I think it's maybe visually a little neater to use autorelease, but
either way works and I would probably do it the other way in different
circumstances. Feel free to change it if you want.

> Presumably 'atitle' should be sent autorelease (or release) as well?

Yes, I missed that one. And actually, I think the alloc'd NSMenuItem
on line 484 will need released too. It should probably be autoreleased
because it's returned to the calling function, and the caller can then
decide whether to retain it or not (it doesn't in this case).

-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Wed, 30 Dec 2020 12:20:02 GMT) Full text and rfc822 format available.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 45502 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Wed, 30 Dec 2020 13:19:48 +0100
[Message part 1 (text/plain, inline)]
30 dec. 2020 kl. 00.49 skrev Alan Third <alan <at> idiocy.org>:

> I think it's maybe visually a little neater to use autorelease, but
> either way works and I would probably do it the other way in different
> circumstances. Feel free to change it if you want.

Thanks, I'm sticking to autorelease for uniformity here; slightly delayed deallocation is no worse than GC after all.

>> Presumably 'atitle' should be sent autorelease (or release) as well?
> 
> Yes, I missed that one. And actually, I think the alloc'd NSMenuItem
> on line 484 will need released too. It should probably be autoreleased
> because it's returned to the calling function, and the caller can then
> decide whether to retain it or not (it doesn't in this case).

Yes, fixed.

(By the way, 'chording' isn't quite the same as a multi-key sequence; chords are rather simultaneous presses, like C-M-x, no? To continue a musical metaphor, perhaps an Emacs key sequence is an arpeggio?)

Here is a slightly less ugly variant of the symbol substitution patch. Maybe we should apply it and see if there are any complaints, or if we turn against it ourselves later on?

[0001-Use-standard-key-symbols-in-NS-menu-entries.patch (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Wed, 30 Dec 2020 12:48:02 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 45502 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Wed, 30 Dec 2020 12:46:52 +0000
On Wed, Dec 30, 2020 at 01:19:48PM +0100, Mattias Engdegård wrote:
> 30 dec. 2020 kl. 00.49 skrev Alan Third <alan <at> idiocy.org>:
> 
> (By the way, 'chording' isn't quite the same as a multi-key
> sequence; chords are rather simultaneous presses, like C-M-x, no? To
> continue a musical metaphor, perhaps an Emacs key sequence is an
> arpeggio?)

Good point. I thought about it for a while and wasn't really sure what
to write, so my comment wasn't very good even ignoring that. :)

> Here is a slightly less ugly variant of the symbol substitution
> patch. Maybe we should apply it and see if there are any complaints,
> or if we turn against it ourselves later on?

It looks good to me, so I see no reason not to apply it and see if
anyone complains.

Oh, I noticed that the Mark menu in dired has the Help menu search
entry. I guess I've missed something somewhere. I wondered if that was
set somewhere but couldn't see any reference to it so assumed macOS
was doing something clever when it saw a "Help" top level submenu...

BTW, this isn't a comment on your code, I'm just curious. I notice you
use C functions within Obj C classes where I would probably have just
created another method. Is that just because they're dealing with C
code exclusively or something else?

-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Wed, 30 Dec 2020 13:10:01 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>,
 45502 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Wed, 30 Dec 2020 13:09:02 +0000
On Wed, Dec 30, 2020 at 12:46:52PM +0000, Alan Third wrote:
> Oh, I noticed that the Mark menu in dired has the Help menu search
> entry. I guess I've missed something somewhere. I wondered if that was
> set somewhere but couldn't see any reference to it so assumed macOS
> was doing something clever when it saw a "Help" top level submenu...

Ah, got it!

modified   src/nsmenu.m
@@ -365,6 +365,9 @@
       else
         submenu = [menu addSubmenuWithTitle: wv->name];
 
+      if ([[submenu title] isEqualToString:@"Help"])
+        [NSApp setHelpMenu:submenu];
+
       if (deep_p)
         [submenu fillWithWidgetValue: wv->contents];


-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#45502; Package emacs. (Wed, 30 Dec 2020 13:13:02 GMT) Full text and rfc822 format available.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 45502 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Wed, 30 Dec 2020 14:12:32 +0100
30 dec. 2020 kl. 13.46 skrev Alan Third <alan <at> idiocy.org>:

> It looks good to me, so I see no reason not to apply it and see if
> anyone complains.

Good, will do.

> Oh, I noticed that the Mark menu in dired has the Help menu search
> entry. I guess I've missed something somewhere. I wondered if that was
> set somewhere but couldn't see any reference to it so assumed macOS
> was doing something clever when it saw a "Help" top level submenu...

It's on the menu with the same index as Help normally has (because Dired adds multiple menus to the bar); the same effect can be seen in M-x shell. Perhaps we manage to confuse the Cocoa automatics somehow?

> BTW, this isn't a comment on your code, I'm just curious. I notice you
> use C functions within Obj C classes where I would probably have just
> created another method. Is that just because they're dealing with C
> code exclusively or something else?

It's mostly accidental, but it is true that there is a tension between different styles here -- I find plain functions to be fine for doing the job of a function (being a functional programmer at heart helps, of course...) and Objective-C allows it seamlessly. Methods don't bring much when they don't somehow operate on the object state, and they require declaration in the .h file even if only used locally (I might be mistaken here).

Thus no religion here; I can do it either way.





Reply sent to Mattias Engdegård <mattiase <at> acm.org>:
You have taken responsibility. (Wed, 30 Dec 2020 15:54:01 GMT) Full text and rfc822 format available.

Notification sent to Mattias Engdegård <mattiase <at> acm.org>:
bug acknowledged by developer. (Wed, 30 Dec 2020 15:54:02 GMT) Full text and rfc822 format available.

Message #52 received at 45502-done <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 45502-done <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#45502: [PATCH] Prettier key bindings in NS menu entries
Date: Wed, 30 Dec 2020 16:53:04 +0100
30 dec. 2020 kl. 14.09 skrev Alan Third <alan <at> idiocy.org>:

> Ah, got it!

Good catch! I think we've squeezed this bug dry by now; closing.





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 28 Jan 2021 12:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 60 days ago.

Previous Next


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