Modify menu-bar help

Modify menu-bar help

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

Hi all,

hoping someone can help me with a problem I'm having when trying to add a
new item to a top level menu. The item is an action rather than another
menu. I'm doing this to fix some code that worked in emacs 21, but does not
work in emacs 23 (or emacs 22 I believe). I've tried to boil it down to a
basic recipe shown below.

I'm experimenting in the scratch buffer. This is in emacs 24.0.50 on Linux,
but the problem occurs under windows as well.

; a simple test action
(defun tx-greet ()
  (interactive)
  (message "Hello Tim!"))

If I execute

(defun tx-menu ()
  (interactive)
  (define-key lisp-interaction-mode-map [menu-bar tx]
    (cons "TX" (make-sparse-keymap)))
  (define-key lisp-interaction-mode-map [menu-bar tx tx-test]
    '(menu-item "TX Test" tx-greet)))

I get a new menu item "TX" and clicking on that gives a sub-menu with one
item "TX Test". Clicking on this item and the message "Hello Tim!" appears
in the minibuffer. All works as expected.

However, if I just define the function as

(defun tx-menu ()
  (interactive)
  (define-key lisp-interaction-mode-map [menu-bar tx]
    '(menu-item "TX Test" tx-greet)))

I get the expected menu item at the top level, but clicking on it does
nothing - well, it grabs focus, the item is highlighted and you have to
click again to release focus.

So, what am I doing wrong? I've looked at menu-bar.el and I believe my code
is the same as other examples in that file which add a top level menu action
i.e. quit for the ns port etc. According to the manual, the definition looks
OK and presumably a similar definition use to work in emacs 21. I've checked
the NEWS files and cannot see anything which looks relevant. Can someone
give me some clues as at this point, I'm stumped!

thanks,

Tim

[-- Attachment #2: Type: text/html, Size: 2379 bytes --]

RE: Modify menu-bar help

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

(defun tx-greet ()
  (interactive) 
  (message "Hello Tim!"))

(defun tx-menu ()
  (interactive)
  (define-key lisp-interaction-mode-map [menu-bar tx]
    '(menu-item "TX Test" tx-greet)))

I get the expected menu item at the top level, but clicking on it does nothing -
well, it grabs focus, the item is highlighted and you have to click again to
release focus. 

So, what am I doing wrong?

Doing just what you said works for me.  I get a `TX Test' menu at the top level.
Clicking it shows the message `Hello Tim!'. I used a recent Windows build of
Emacs 24 (emacs -Q).
 
Did you test with `emacs -Q'?
Did you remember to do `M-x t-menu'? ;-)
Did you look in *Messages* for the message (in case it was too quick).
 
Did you already have a *scratch* buffer (or other buffer in Lisp Interaction
Mode).
If so, try killing it and revisiting (recreating) it.
(But if you see the menu `TX Test' then it should be OK.)
 
You can also try running the functions on `menu-bar-update-hook'.
Or (run-hooks 'activate-menubar-hook 'menu-bar-update-hook).
But again if you see `TX Test' then it should be OK.
(IOW, I don't know what's wrong, sorry.)
 
HTH - Drew

 

[-- Attachment #2: Type: text/html, Size: 3986 bytes --]

Re: Modify menu-bar help

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]

On Fri, Feb 25, 2011 at 11:52 AM, Drew Adams <drew.adams@oracle.com> wrote:

>  (defun tx-greet ()
>    (interactive)
>   (message "Hello Tim!"))
>
> (defun tx-menu ()
>    (interactive)
>   (define-key lisp-interaction-mode-map [menu-bar tx]
>     '(menu-item "TX Test" tx-greet)))
>
> I get the expected menu item at the top level, but clicking on it does
> nothing - well, it grabs focus, the item is highlighted and you have to
> click again to release focus.
>
> So, what am I doing wrong?
>
>  Doing just what you said works for me.  I get a `TX Test' menu at the top
> level. Clicking it shows the message `Hello Tim!'. I used a recent Windows
> build of Emacs 24 (emacs -Q).
>
> Did you test with `emacs -Q'?
> Did you remember to do `M-x t-menu'? ;-)
> Did you look in *Messages* for the message (in case it was too quick).
>
> Did you already have a *scratch* buffer (or other buffer in Lisp
> Interaction Mode).
> If so, try killing it and revisiting (recreating) it.
> (But if you see the menu `TX Test' then it should be OK.)
>
> You can also try running the functions on `menu-bar-update-hook'.
> Or (run-hooks 'activate-menubar-hook 'menu-bar-update-hook).
> But again if you see `TX Test' then it should be OK.
> (IOW, I don't know what's wrong, sorry.)
>
>
Hi Drew,

thanks for the response. It doesn't work for me with emacs -Q. I get the
menu item right before the lisp-interaction menu, but clicking on it just
highlights it and nothing happens, except the focus is stolen and you cannot
do anything until you click on it a second time. There is nothing in the
messages buffer apart from the tx-greet and tx-menu lines that are added
when you evaluate the functions. I can run tx-greet and it does what it
should and running the tx-menu adds the entry which does nothing. There is
no other scratch buffer.

I'm running a recent (last couple of days) version of emacs 24 from bzr.
I'll update and try again.  Sems odd it will work for you but not me when we
are running similar versions, but a windows build v linux 64bit build.  I'll
also try with latest emacs 23 and see if I get the same issue.

It would be good if someone else can try on Linux (especially 64bit) and it
would be interesting to know if it works with a build using the old X11 libs
rather than gtk, just to rule that out as the difference.

If nobody can see a problem with the code I'm using, I'm suspecting it is
either a bug or an undocumented feature (i.e. cannot have menu acitons at
the top level, only sub-menus since the same code appears to work fine if it
is in a sub-menu).

Tim





>

>
>

[-- Attachment #2: Type: text/html, Size: 5510 bytes --]

RE: Modify menu-bar help

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]

I'm running a recent (last couple of days) version of emacs 24 from bzr. I'll
update and try again.  Sems odd it will work for you but not me when we are
running similar versions, but a windows build v linux 64bit build.  I'll also
try with latest emacs 23 and see if I get the same issue. 

It would be good if someone else can try on Linux (especially 64bit) and it
would be interesting to know if it works with a build using the old X11 libs
rather than gtk, just to rule that out as the difference. 

If nobody can see a problem with the code I'm using, I'm suspecting it is either
a bug or an undocumented feature (i.e. cannot have menu acitons at the top
level, only sub-menus since the same code appears to work fine if it is in a
sub-menu).

I used this version for the test:
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-02-14 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'

Perhaps something was changed since then which breaks things?

[-- Attachment #2: Type: text/html, Size: 1901 bytes --]

Re: Modify menu-bar help

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 24 Feb 2011 16:52:30 -0800
> Cc: 
> 
> Doing just what you said works for me.  I get a `TX Test' menu at the top level.
> Clicking it shows the message `Hello Tim!'. I used a recent Windows build of
> Emacs 24 (emacs -Q).

With today's build on MS-Windows, I do see the greeting, FWIW.

Re: Modify menu-bar help

[Eli Zaretskii]

> Date: Fri, 25 Feb 2011 16:14:17 +1100
> From: Tim Cross <theophilusx@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> It doesn't work for me with emacs -Q. I get the
> menu item right before the lisp-interaction menu, but clicking on it just
> highlights it and nothing happens, except the focus is stolen and you cannot
> do anything until you click on it a second time.

Does the greeting appear when you click the second time?

This is probably specific to the toolkit you are using to build Emacs.
I would suggest to build with a different toolkit, or without any
toolkits, and see if the problem exists in that other build.

Re: Modify menu-bar help

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 24 Feb 2011 23:15:37 -0800
> Cc: emacs-devel@gnu.org
> 
> I used this version for the test:
> In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
>  of 2011-02-14 on 3249CTO
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (4.4) --no-opt --cflags
> -Ic:/imagesupport/include'
> 
> Perhaps something was changed since then which breaks things?

No.  It still works.

Re: Modify menu-bar help

[Jan Djärv]

2011-02-25 06:14, Tim Cross skrev:
>
>
> On Fri, Feb 25, 2011 at 11:52 AM, Drew Adams <drew.adams@oracle.com
> <mailto:drew.adams@oracle.com>> wrote:
>
>         (defun tx-greet ()
>            (interactive)
>            (message "Hello Tim!"))
>
>         (defun tx-menu ()
>            (interactive)
>            (define-key lisp-interaction-mode-map [menu-bar tx]
>         '(menu-item "TX Test" tx-greet)))
>
>         I get the expected menu item at the top level, but clicking on it does
>         nothing - well, it grabs focus, the item is highlighted and you have
>         to click again to release focus.
>
>         So, what am I doing wrong?
>
>     Doing just what you said works for me.  I get a `TX Test' menu at the top
>     level. Clicking it shows the message `Hello Tim!'. I used a recent Windows
>     build of Emacs 24 (emacs -Q).
>     Did you test with `emacs -Q'?
>     Did you remember to do `M-x t-menu'? ;-)
>     Did you look in *Messages* for the message (in case it was too quick).
>     Did you already have a *scratch* buffer (or other buffer in Lisp
>     Interaction Mode).
>     If so, try killing it and revisiting (recreating) it.
>     (But if you see the menu `TX Test' then it should be OK.)
>     You can also try running the functions on `menu-bar-update-hook'.
>     Or (run-hooks 'activate-menubar-hook 'menu-bar-update-hook).
>     But again if you see `TX Test' then it should be OK.
>     (IOW, I don't know what's wrong, sorry.)
>
> Hi Drew,
>
> thanks for the response. It doesn't work for me with emacs -Q. I get the menu
> item right before the lisp-interaction menu, but clicking on it just
> highlights it and nothing happens, except the focus is stolen and you cannot
> do anything until you click on it a second time. There is nothing in the
> messages buffer apart from the tx-greet and tx-menu lines that are added when
> you evaluate the functions. I can run tx-greet and it does what it should and
> running the tx-menu adds the entry which does nothing. There is no other
> scratch buffer.
>
> I'm running a recent (last couple of days) version of emacs 24 from bzr. I'll
> update and try again.  Sems odd it will work for you but not me when we are
> running similar versions, but a windows build v linux 64bit build.  I'll also
> try with latest emacs 23 and see if I get the same issue.
>
> It would be good if someone else can try on Linux (especially 64bit) and it
> would be interesting to know if it works with a build using the old X11 libs
> rather than gtk, just to rule that out as the difference.
>
> If nobody can see a problem with the code I'm using, I'm suspecting it is
> either a bug or an undocumented feature (i.e. cannot have menu acitons at the
> top level, only sub-menus since the same code appears to work fine if it is in
> a sub-menu).

It is a Gtk+ thing.  Menubars are only supposed to have menus, not buttons. 
Buttons should go in tool bars.  You can't even put in buttons in a Gtk+ menu 
bar, you can only put in menu items, and they tend to "steal" all mouse 
presses before Emacs sees them.  Maybe there is a way around this, but it is 
not worth it.  Besides, we always create an empty sub menu if there isn't one 
because some themes assume a submenu and draws things incorrectly if there 
isn't one.

	Jan D.


	Jan D.

Re: Modify menu-bar help

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 4039 bytes --]

On Fri, Feb 25, 2011 at 9:03 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:

> 2011-02-25 06:14, Tim Cross skrev:
>
>>
>>
>> On Fri, Feb 25, 2011 at 11:52 AM, Drew Adams <drew.adams@oracle.com
>> <mailto:drew.adams@oracle.com>> wrote:
>>
>>        (defun tx-greet ()
>>           (interactive)
>>           (message "Hello Tim!"))
>>
>>        (defun tx-menu ()
>>           (interactive)
>>           (define-key lisp-interaction-mode-map [menu-bar tx]
>>        '(menu-item "TX Test" tx-greet)))
>>
>>        I get the expected menu item at the top level, but clicking on it
>> does
>>        nothing - well, it grabs focus, the item is highlighted and you
>> have
>>        to click again to release focus.
>>
>>        So, what am I doing wrong?
>>
>>    Doing just what you said works for me.  I get a `TX Test' menu at the
>> top
>>    level. Clicking it shows the message `Hello Tim!'. I used a recent
>> Windows
>>    build of Emacs 24 (emacs -Q).
>>    Did you test with `emacs -Q'?
>>    Did you remember to do `M-x t-menu'? ;-)
>>    Did you look in *Messages* for the message (in case it was too quick).
>>    Did you already have a *scratch* buffer (or other buffer in Lisp
>>    Interaction Mode).
>>    If so, try killing it and revisiting (recreating) it.
>>    (But if you see the menu `TX Test' then it should be OK.)
>>    You can also try running the functions on `menu-bar-update-hook'.
>>    Or (run-hooks 'activate-menubar-hook 'menu-bar-update-hook).
>>    But again if you see `TX Test' then it should be OK.
>>    (IOW, I don't know what's wrong, sorry.)
>>
>> Hi Drew,
>>
>> thanks for the response. It doesn't work for me with emacs -Q. I get the
>> menu
>> item right before the lisp-interaction menu, but clicking on it just
>> highlights it and nothing happens, except the focus is stolen and you
>> cannot
>> do anything until you click on it a second time. There is nothing in the
>> messages buffer apart from the tx-greet and tx-menu lines that are added
>> when
>> you evaluate the functions. I can run tx-greet and it does what it should
>> and
>> running the tx-menu adds the entry which does nothing. There is no other
>> scratch buffer.
>>
>> I'm running a recent (last couple of days) version of emacs 24 from bzr.
>> I'll
>> update and try again.  Sems odd it will work for you but not me when we
>> are
>> running similar versions, but a windows build v linux 64bit build.  I'll
>> also
>> try with latest emacs 23 and see if I get the same issue.
>>
>> It would be good if someone else can try on Linux (especially 64bit) and
>> it
>> would be interesting to know if it works with a build using the old X11
>> libs
>> rather than gtk, just to rule that out as the difference.
>>
>> If nobody can see a problem with the code I'm using, I'm suspecting it is
>> either a bug or an undocumented feature (i.e. cannot have menu acitons at
>> the
>> top level, only sub-menus since the same code appears to work fine if it
>> is in
>> a sub-menu).
>>
>
> It is a Gtk+ thing.  Menubars are only supposed to have menus, not buttons.
> Buttons should go in tool bars.  You can't even put in buttons in a Gtk+
> menu bar, you can only put in menu items, and they tend to "steal" all mouse
> presses before Emacs sees them.  Maybe there is a way around this, but it is
> not worth it.  Besides, we always create an empty sub menu if there isn't
> one because some themes assume a submenu and draws things incorrectly if
> there isn't one.
>
>        Jan D.
>
>
>        Jan D.
>
> Thanks everyone for your input. Jan, you confirm what I suspected. I will
try to build with the old X athena libs and see if it works (which I expect
it will).

This strikes me as something that should be in the manual. Would everyone
agree it would be worth lodging a bug report to have this information added
as a footnote or reference i.e. that you cannot add menu actions/buttons to
the top level menu when using gtk_?

Tim

[-- Attachment #2: Type: text/html, Size: 4787 bytes --]

RE: Modify menu-bar help

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

This strikes me as something that should be in the manual. Would everyone agree
it would be worth lodging a bug report to have this information added as a
footnote or reference i.e. that you cannot add menu actions/buttons to the top
level menu when using gtk_? 

Yes, sounds like useful info to me. And info that it might not be easy to
discover otherwise (modulo writing to emacs-devel as you did). Even if this is
not Emacs-specific but is general to GTK, an Emacs user thinks of the menus as
Emacs menus, not necessarily as GTK menus.

[-- Attachment #2: Type: text/html, Size: 1154 bytes --]

Re: Modify menu-bar help

[Eli Zaretskii]

> Date: Sat, 26 Feb 2011 01:49:29 +1100
> From: Tim Cross <theophilusx@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> This strikes me as something that should be in the manual. Would everyone
> agree it would be worth lodging a bug report to have this information added
> as a footnote or reference i.e. that you cannot add menu actions/buttons to
> the top level menu when using gtk_?

No.  We don't document bugs, unless they are certain to be more or
less permanent misfeatures.

RE: Modify menu-bar help

[Drew Adams]

> > This strikes me as something that should be in the manual. 
> > Would everyone agree it would be worth lodging a bug report
> > to have this information added as a footnote or reference
> > i.e. that you cannot add menu actions/buttons to
> > the top level menu when using gtk_?
> 
> No.  We don't document bugs, unless they are certain to be more or
> less permanent misfeatures.

Ah, I agree.  If this is considered a bug then we should not document it.

In my previous reply I was thinking that Emacs Dev considered this to be part of
the design, with no plan to fix it.  Bugs and bug workarounds generally should
not be documented in the manual (but could be documented in release notes etc.).

Re: Modify menu-bar help

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <jan.h.d@swipnet.se>, <emacs-devel@gnu.org>
> Date: Fri, 25 Feb 2011 07:38:47 -0800
> 
> Ah, I agree.  If this is considered a bug then we should not document it.
> 
> In my previous reply I was thinking that Emacs Dev considered this to be part of
> the design, with no plan to fix it.

As I understand from Jan, this is a GTK bug.

> Bugs and bug workarounds generally should not be documented in the
> manual (but could be documented in release notes etc.).

We could put it in etc/PROBLEMS, I guess, if we think GTK will not
solve this soon enough.

Re: Modify menu-bar help

[Jan Djärv]

Eli Zaretskii skrev 2011-02-25 16.54:
>> From: "Drew Adams"<drew.adams@oracle.com>
>> Cc:<jan.h.d@swipnet.se>,<emacs-devel@gnu.org>
>> Date: Fri, 25 Feb 2011 07:38:47 -0800
>>
>> Ah, I agree.  If this is considered a bug then we should not document it.
>>
>> In my previous reply I was thinking that Emacs Dev considered this to be part of
>> the design, with no plan to fix it.
>
> As I understand from Jan, this is a GTK bug.

It is a deliberate limitation imposed on menu bars.  I doubt that Gtk+ people 
will consider this as a bug.

>
>> Bugs and bug workarounds generally should not be documented in the
>> manual (but could be documented in release notes etc.).
>
> We could put it in etc/PROBLEMS, I guess, if we think GTK will not
> solve this soon enough.

As they probably don't think anything is wrong, they will never "solve" this.

	Jan D.

RE: Modify menu-bar help

[Drew Adams]

> It is a deliberate limitation imposed on menu bars.  I doubt 
> that Gtk+ people will consider this as a bug.
> 
> >> Bugs and bug workarounds generally should not be documented in the
> >> manual (but could be documented in release notes etc.).
> >
> > We could put it in etc/PROBLEMS, I guess, if we think GTK will not
> > solve this soon enough.
> 
> As they probably don't think anything is wrong, they will 
> never "solve" this.

In that case I think it has to be considered a design limitation/choice for
Emacs.

IOW, as long as Emacs (on some platforms) is designed to use GTK, which has this
limitation (deliberate design, apparently), this is not an Emacs bug but is part
of the Emacs design.  In that case, it should perhaps be documented in the
manual.

In general, users should be able to easily find out whether some known behavior
is considered a bug (which has some hope of being fixed) or is part of the
design.

Re: Modify menu-bar help

[Ben Key]

[-- Attachment #1: Type: text/plain, Size: 232 bytes --]

Hello,

If we do document this issue somewhere we should note that GTK is not the
only environment in which this is an issue.  I tried using the code provided
by Tim Cross on the Nextstep build of Emacs 24 and had the same problem.

[-- Attachment #2: Type: text/html, Size: 273 bytes --]

Re: Modify menu-bar help

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

On Sat, Feb 26, 2011 at 7:33 AM, Ben Key <bkey76@gmail.com> wrote:

> Hello,
>
> If we do document this issue somewhere we should note that GTK is not the
> only environment in which this is an issue.  I tried using the code provided
> by Tim Cross on the Nextstep build of Emacs 24 and had the same problem.
>
> Just to clarify my thoughts re: reporting this as a 'bug' for the emacs
manual. Iff the reason this won't work is due to a deliberate design
decision in the toolkit, then I think this limitation should be mentioned in
the manual - even if its just a footnote indicating that under some GUI
toolkits, you canot create top-level menu actions that are not sub-menus
i.e. a button. From Jan's post, my impression was that this behavior is not
a bug, but rather a feature of the GTK design i.e. deliberate.

However, I think this still needs more work for confirmation. I plan to
build with the old lucid toolkit and see if it works. If it does, then it
gives mroe evidence that this is the case. I will also try and find
confirmation in the GTK+ manual.

I'm a bit surprised that the same problem seems to occur under the NextStep
OS - while I'm not expert here and could have things confused, it looked to
me like the ns version added menu 'buttons' when I scanned the menu-bar.el
file.

I will try to confirm things further and substantiate that this is a GTK+
limitation (not questioning Jan's post, just feel we should verify
carefully) and if appropriate, will log a bug report suggesting the manual
is updated to reference toolkit limitations.

Any objections or suggestions?

Tim

[-- Attachment #2: Type: text/html, Size: 2034 bytes --]

Re: Modify menu-bar help

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 225 bytes --]

Just confirming that the test code works fine with emacs when built with the
Lucid toolkit. So, the issue does seem toolkit specific. I will now see if I
can find confirmation this is a GTK+ 'feature' from the GTK docs.

Tim

[-- Attachment #2: Type: text/html, Size: 284 bytes --]

Re: Modify menu-bar help

[Jan Djärv]

Tim Cross skrev 2011-02-26 02.04:
>
> Just confirming that the test code works fine with emacs when built with the
> Lucid toolkit. So, the issue does seem toolkit specific. I will now see if I
> can find confirmation this is a GTK+ 'feature' from the GTK docs.
>

I don't think this is documented, it is more how assertions in the code are 
placed and how things work that makes this policy explicit.  After all, it 
isn't documented that you can't put tool-bars, file dialogs or other menu bars 
in a menu bar.  But you can't.

	Jan D.

Re: Modify menu-bar help

[Jan Djärv]

Tim Cross skrev 2011-02-26 00.58:
>
> I'm a bit surprised that the same problem seems to occur under the NextStep OS
> - while I'm not expert here and could have things confused, it looked to me
> like the ns version added menu 'buttons' when I scanned the menu-bar.el file.
>

Menu-bar.el has nothing to do with how things are implemented at the toolkit 
level.  Looking at it gives no clue what so ever.

	Jan D.

Re: Modify menu-bar help

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]

On Sat, Feb 26, 2011 at 9:22 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:

>
>
> Tim Cross skrev 2011-02-26 00.58:
>
>
>> I'm a bit surprised that the same problem seems to occur under the
>> NextStep OS
>> - while I'm not expert here and could have things confused, it looked to
>> me
>> like the ns version added menu 'buttons' when I scanned the menu-bar.el
>> file.
>>
>>
> Menu-bar.el has nothing to do with how things are implemented at the
> toolkit level.  Looking at it gives no clue what so ever.
>
>        Jan D.
>
> This was my mis-reading/remembering of the code in menu-bar.el. I thought
there was code in menu-bar.el that was adding 'action' menus 'buttons' at
the top level in the ns port, but looking at it again, I realise this is for
the GNUStep version. My (flawed) logic was that if menu-bar.el is adding top
level action buttons for a version, then the tookit used for that version
must allow it. I think my logic is OK, it was my scanning of the code that
led to the wrong conclusion! The code in quesiton was
(if (not (featurep 'ns))
    ;; Force Help item to come last, after the major mode's own items.
    ;; The symbol used to be called `help', but that gets confused with the
    ;; help key.
    (setq menu-bar-final-items '(help-menu))
  (if (eq system-type 'darwin)
      (setq menu-bar-final-items '(buffer services help-menu))
    (setq menu-bar-final-items '(buffer services hide-app quit))
    ;; Add standard top-level items to GNUstep menu.
    (define-key global-map [menu-bar quit]
      `(menu-item ,(purecopy "Quit") save-buffers-kill-emacs
                  :help ,(purecopy "Save unsaved buffers, then exit")))
    (define-key global-map [menu-bar hide-app]
      `(menu-item ,(purecopy "Hide") ns-do-hide-emacs
                  :help ,(purecopy "Hide Emacs"))))
  (define-key global-map [menu-bar services] ; set-up in ns-win
    (cons (purecopy "Services") (make-sparse-keymap "Services"))))

Tim

[-- Attachment #2: Type: text/html, Size: 2720 bytes --]