Emacs menu doesn't come up right

I see almost the same behavior, when I use emacs (Gtk version on linux) I get:

VM->help->Switch to Emacs toolbar, nothing, click, get emacs toolbar
emacs toolbar->VM,nothing ever

I normally use the -nw switch for console mode, and I do not see this bug, I can
move between menus without problem. So I think this is Emacs+(graphical backend)
bug, i.e. Emacs+GTK or Emacs+Windows

This is being a very tenacious little bug. In fact it is beginning to look more and more like an emacs issue rather than a vm one.

First of all, I'm not getting the same observed behavior. The Help->Switch to emacs toolbar option works as expected for me with latest emacs 24. However, the top-level [VM] option to switch back to the vm menu does nothing (apart from stealing focus - you have to click a second time to regain focus. You can restore the vm menu by manually running M-x vm-menu-toggle-menubar.

I have distilled things down to a simple test case to add a menu to the scratch buffer. The code shows the same exact problem. However, if you add an item in the same way to a sub-menu (i.e. not a top level menu) then the code woks as expected. It appears there is some issue with adding top-level menu actions (as opposed to top level sub-menus).

I have had one report that the test code worked under a recent build of emacs 24 for windows. maybe the problem is fixed there?

Will now test under recent emacs 24 and latest emacs 23 to see if it makes any difference. Waiting to see what responses I get to my post to the emacs-devel list - will likely lodge a bug report for emacs.

The test case I've been using is outline in the post I made to emacs-dev and gnu.emacs.help - copied below for reference....

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

Hi Tim, thanks for looking into this. Your test example works for me on Emacs23. But VM's menubar misbehaves.

On Fri, Feb 25, 2011 at 8:19 PM, Uday Reddy <email address hidden> wrote:

> Hi Tim, thanks for looking into this. Your test example works for me on
> Emacs23. But VM's menubar misbehaves.
>
> I believe we have two problems interacting here. The VM definition isn't
quite right wrt changes in emacs 23. However, it seems we have a larger
issue. Apparently, you cannot have top level menu 'actions' under emacs when
built with gtk. This is not an issue on windows, but it is an issue if we
want a solution that will work under both windows and gtk_ versions.

I have a couple of ideas, but want some time to think and possibly try a few
things out. I suspect we may need to re-thing how this all works if we want
this functionality to work cross-platform.

Tim

On Emacs23/Win32, I get

- a menubar item "Help" -> "Switch to Emacs Toolbar" on the VM menubar
- and a button "[VM]" on the Emacs menubar

both of which require two clicks to do anything. We can change the
latter to

- "VM" -> "Switch to VM Menubar" on the Emacs menubar

and that would be symmetric. I think "Toolbar" above is a misspelling
of "menubar".

On XEmacs, I get menubar buttons that say

- "XEmacs" on VM menubar and
- "VM" on the XEmacs menubar,

and they both work. But if they are buttons, shouldn't they be
notated "[XEmacs]" and "[VM]"?

Cheers,
Uday

On Sat, Feb 26, 2011 at 11:33 AM, Uday S Reddy <email address hidden>wrote:

> On Emacs23/Win32, I get
>
> - a menubar item "Help" -> "Switch to Emacs Toolbar" on the VM menubar
> - and a button "[VM]" on the Emacs menubar
>
> both of which require two clicks to do anything. We can change the
> latter to
>
> - "VM" -> "Switch to VM Menubar" on the Emacs menubar
>

Hehe - was just about to post suggesting exactly that solution. It would
seem at least two of the toolkits (GTK+/NS) don't support top level
'buttons', so for the fsf emacs, to be consistent, I think we should have
"VM" -> "Switch to VM Menubar" as you suggest.

> and that would be symmetric. I think "Toolbar" above is a misspelling
> of "menubar".
>
> Bingo! That was going to be my second question as I too thought it should
say "Menubar" not "Toolbar".

> On XEmacs, I get menubar buttons that say
>
> - "XEmacs" on VM menubar and
> - "VM" on the XEmacs menubar,
>
> and they both work. But if they are buttons, shouldn't they be
> notated "[XEmacs]" and "[VM]"?
>
> Yes, I think your right. I've never seen any documentation which suggests
this, but it does seem to be a common convention and I think it is good to
have some visual indicator that when you click that item, it will cause an
action, not open another menu.

I also suspect we have another possible issue with the fsf emacs menus that
only affects the Windows platform. I see slightly different behavior to what
you report on
windows. Therefore, I suggest I fix what I can, test with GTK and Lucid
builds of emacs and if I can XEmacs and push it up to launchpad. If you
could then review the changes and see if it works for the windows version.
If it does, great and if your happy, merge. If it doesn't, I'm afraid you
may need to look at it as I cannot test/debug under windows.

With luck, I'll have the GTK/Lucid/Xemacs fixes for this bug done today or
tomorrow.

Tim (who is now even more convinced menus are overrated! :-)

>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~vm
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~vm
> More help : https://help.launchpad.net/ListHelp
>

Have committed a fix that makes the changes discussed above.
The problem with menubar not updating and needing a second mouse click (or cursor movement or just wait for a minute or so) appears to be some sort of redisplay/timing issue and possibly an emacs bug. Have applied a temporary work around that appears to work under Emacs built with GTK. Needs further investigation.

Tim Cross writes:

> I also suspect we have another possible issue with the fsf emacs menus that
> only affects the Windows platform. I see slightly different behavior to what
> you report on
> windows. Therefore, I suggest I fix what I can, test with GTK and Lucid
> builds of emacs and if I can XEmacs and push it up to launchpad. If you
> could then review the changes and see if it works for the windows version.
> If it does, great and if your happy, merge. If it doesn't, I'm afraid you
> may need to look at it as I cannot test/debug under windows.

It didn't work on Windows. It also didn't work on this Linux version
that I have in my department.

GNU Emacs 22.2.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2008-05-07 on milo

So, something more is needed. But I am going to merge your current
changes anyway.

Cheers,
Uday

Hi Tim, I found a reasonable work-around for the
force-mode-line-update problem and committed it. Revision 1104.

It would be good if you can add another menubar item to the VM
menubar.

 "Emacs" -> "Switch to Emacs menubar"

This is in addition to the "Help" -> "Switch to Emacs menubar" item.
(I find it a bit counter-intuitive to go to the Help menu to do this.)

Cheers,
Uday

On Sun, Feb 27, 2011 at 1:13 AM, Uday S Reddy <email address hidden>wrote:

> Hi Tim, I found a reasonable work-around for the
> force-mode-line-update problem and committed it. Revision 1104.
>
> It would be good if you can add another menubar item to the VM
> menubar.
>
> "Emacs" -> "Switch to Emacs menubar"
>
> This is in addition to the "Help" -> "Switch to Emacs menubar" item.
> (I find it a bit counter-intuitive to go to the Help menu to do this.)
>
> Cheers,
> Uday
>
> OK, will add Emacs -> Switch To Emacs menubar. In fact, I think, from
> memory, this is what it use to be. For consistency, I'll try and add it to
> the xemacs menus as well. Do you think we should just remove the entry from
> the help menu as well? It seems a little redundent and I too think it seems
> a little unintuitive.
>

Tim

> _______________________________________________
> Mailing list: https://launchpad.net/~vm
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~vm
> More help : https://help.launchpad.net/ListHelp
>

Tim Cross writes:

> > OK, will add Emacs -> Switch To Emacs menubar. In fact, I think, from
> > memory, this is what it use to be. For consistency, I'll try and add it to
> > the xemacs menus as well. Do you think we should just remove the entry from
> > the help menu as well? It seems a little redundent and I too think it seems
> > a little unintuitive.

My memory is that we used to have menu buttons "[VM]" and "[Emacs]".
It is still that way for XEmacs.

The "[Emacs]" button was moved to the Help menu in VM 8.0.8 according
to the NEWS file, but the "[VM]' button was retained on the menubar
and it is probably broken for GTK users.

I think it is to leave another copy under "Help" because some people
might have gotten used to looking there.

Cheers,
Uday

Uday Reddy writes:

> My memory is that we used to have menu buttons "[VM]" and "[Emacs]".
> It is still that way for XEmacs.
>
> The "[Emacs]" button was moved to the Help menu in VM 8.0.8 according
> to the NEWS file, but the "[VM]' button was retained on the menubar
> and it is probably broken for GTK users.

It also occurs to me that it would be nice if we can implement this
modularly so that we can pick either menubar buttons or menus,
depending on the toolkit in operation. Rob seems to have thought that
buttons don't work in Win32, but they work fine. They also work fine
in the "X toolkit" used on my CentOS machine at work.

Cheers,
Uday

On Wed, Mar 2, 2011 at 11:08 AM, Uday S Reddy <email address hidden>wrote:

> Uday Reddy writes:
>
> > My memory is that we used to have menu buttons "[VM]" and "[Emacs]".
> > It is still that way for XEmacs.
> >
> > The "[Emacs]" button was moved to the Help menu in VM 8.0.8 according
> > to the NEWS file, but the "[VM]' button was retained on the menubar
> > and it is probably broken for GTK users.
>
> It also occurs to me that it would be nice if we can implement this
> modularly so that we can pick either menubar buttons or menus,
> depending on the toolkit in operation. Rob seems to have thought that
> buttons don't work in Win32, but they work fine. They also work fine
> in the "X toolkit" used on my CentOS machine at work.
>
>
From what I've been able to determine, top-level menu 'buttons' will work
under wn32, X Lucid and I think GNUStep. They do not work under GTK+ or NS.
Don't know about other toolkits.

The difficulty about a modular approach so that we have different behavior
based on the toolkit is that I'm not sure how easily you can detect each
different toolkit at run-time. I'm also concerned we may be just adding
complexity and extra code (= extra bugs) for little real benefit. I'd rather
we had the same/consistent interface on all systems. Apart from less code to
maintain, it gives a consistent feel regardless of the build you are using.
This would mean not having top-level menu buttons as at least two toolkits
don't support it. Personally, I think in the last 15 years, there has only
been one time I used the option to get the emacs menu bar, so maybe I'm not
able to see the real advantage of having the option as a top-level button
compared to having it as an action under a sub-menu.

Tim

P.S. Another thought may be to have this as a toolbar item? I personally
turn off toolbars, but maybe that would be a better solution as all toolkits
support toolbars and essentially, this is what a top-level menu button is.

Tim Cross writes:

> The difficulty about a modular approach so that we have different behavior
> based on the toolkit is that I'm not sure how easily you can detect each
> different toolkit at run-time.

By "modular" I meant defining the menus and buttons as functions, like
it has already been done in vm-menu. Right now, your "switch to VM
Menubar" is hard coded into the toggle-menubar function. It took me a
while to find it when I was exploring things.

If you have all the menus and buttons defined as separate functions,
we can mix and match them depending on the toolkit in operation. We
don't need to do it dynamically, only when VM starts up.

Personally, I think menubars are important because they allow users to
explore the system, and also because they allow access via keyboard.
I don't care that much for toolbars.

Cheers,
Uday

Tim Cross wrote at 03:04 -0000 on Mar 2, 2011:
 > From what I've been able to determine, top-level menu 'buttons' will work
 > under wn32, X Lucid and I think GNUStep. They do not work under GTK+ or NS.
 > Don't know about other toolkits.
 >
 > The difficulty about a modular approach so that we have different behavior
 > based on the toolkit is that I'm not sure how easily you can detect each
 > different toolkit at run-time. I'm also concerned we may be just adding
 > complexity and extra code (= extra bugs) for little real benefit. I'd rather
 > we had the same/consistent interface on all systems. Apart from less code to
 > maintain, it gives a consistent feel regardless of the build you are using.
 > This would mean not having top-level menu buttons as at least two toolkits
 > don't support it. Personally, I think in the last 15 years, there has only
 > been one time I used the option to get the emacs menu bar, so maybe I'm not
 > able to see the real advantage of having the option as a top-level button
 > compared to having it as an action under a sub-menu.
 >
 > Tim
 >
 > P.S. Another thought may be to have this as a toolbar item? I personally
 > turn off toolbars, but maybe that would be a better solution as all toolkits
 > support toolbars and essentially, this is what a top-level menu button is.

Until I saw this bug discussion, I didn't know the problem existed.
Clearly I haven't tried to get at the emacs menubar in a long
time (vm-7.19? under emacs-?).

I can confirm on fedora 14 (emacs 23.2.1, gtk+ 2.21.4, vm 8.1.1) that
the [VM] menubar button doesn't change the menubar under gtk+ (have to
click a second time or escape to "release" the button press and then
nothing changes). I had to use vm-menu-toggle-menubar to get back to
the vm menubar after using 'Switch to Emacs toolbar' under the help
menu (which really changes the menubar, not the toolbar).

I also typically disable toolbars, but the toolbar workaround and/or
submenus is okay with me (two clicks is not that much of an issue for
this - switching menubars is probably? not done that often). There's
also always M-x vm-menu-toggle-menubar. I tend to agree that making
it consistent across toolkits is better from a UI consistency point of
view (and probably simpler than trying to detect toolkits in vm code
and maintain an inventory of which ones work), but don't feel that
strongly.

Unless the vm top level menu button can be fixed in vm (from what's
been tried so far, it sounds like that's hard if not impossible),
trying to fix it in emacs/gtk is probably not a useful resolution of
this bug - even if it can be identified & fixed upstream quickly -
because of legacy versions of emacs in the wild with the bug. Filing
an upstream bug is probably still a good idea.

John Hein writes:

> Unless the vm top level menu button can be fixed in vm (from what's
> been tried so far, it sounds like that's hard if not impossible),
> trying to fix it in emacs/gtk is probably not a useful resolution of
> this bug - even if it can be identified & fixed upstream quickly -
> because of legacy versions of emacs in the wild with the bug. Filing
> an upstream bug is probably still a good idea.

Well, GTK doesn't support menubar menus to act as "buttons". (They
are not buttons actually. They are immediate menu items, rather than
pull-down menus.)

I don't feel like punishing all the other users just because one
toolkit (or two) don't support it. My thinking is, VM normally has
these buttons, and the GTK users will have a work-around.

Cheers,
Uday

On Wed, Mar 2, 2011 at 10:51 PM, Uday S Reddy <email address hidden>wrote:

> John Hein writes:
>
> > Unless the vm top level menu button can be fixed in vm (from what's
> > been tried so far, it sounds like that's hard if not impossible),
> > trying to fix it in emacs/gtk is probably not a useful resolution of
> > this bug - even if it can be identified & fixed upstream quickly -
> > because of legacy versions of emacs in the wild with the bug. Filing
> > an upstream bug is probably still a good idea.
>
> Well, GTK doesn't support menubar menus to act as "buttons". (They
> are not buttons actually. They are immediate menu items, rather than
> pull-down menus.)
>
> I don't feel like punishing all the other users just because one
> toolkit (or two) don't support it. My thinking is, VM normally has
> these buttons, and the GTK users will have a work-around.
>
>
> While I will see what can be done, I think "punishing all the other users"
is a little strong. We are over complicating matters for very little gain
IMO. At least two of the possible toolkits (soon to be three with GTK3+)
don't work, we know two that will and then another 2 or more we have no idea
about.

Moving this functionality to use a sub-menu is not a drastic change really.
At least then we would have the same code base and same interface on all
platforms. The argument to keep top-level action items/buttons would perhaps
have more weight if we were referring to a frequently used operation.

However, my biggest concern is I cannot see any obvious way of determining
which toolkit is being used at runtime. There are some heuristics that could
be applied that may identify some of the toolkits, but there is no variable
that I can see which will reliably report the toolkit. Suggestions would be
welcome.

Tim

>
> _______________________________________________
> Mailing list: https://launchpad.net/~vm
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~vm
> More help : https://help.launchpad.net/ListHelp
>

Dear Tim, I have added a function (vm-menubar-buttons-possible-p) in
vm-version, which you can use to distinguish between the cases.

>  While I will see what can be done, I think "punishing all the other users" is
> a little strong. We are over complicating matters for very little gain IMO. At
> least two of the possible toolkits (soon to be three with GTK3+) don't work,
> we know two that will and then another 2 or more we have no idea about.

I am not sure which toolkits you are talking about here. Can you be
more specific?

> Moving this functionality to use a sub-menu is not a drastic change really. At
> least then we would have the same code base and same interface on all
> platforms. The argument to keep top-level action items/buttons would perhaps
> have more weight if we were referring to a frequently used operation.

Yes, for anybody that uses the menubar, these two buttons would be
among the most frequently used ones. That is why they were made
buttons originally.

Cheers,
Uday

On Fri, Mar 4, 2011 at 5:43 AM, Uday S Reddy <email address hidden>wrote:

> Dear Tim, I have added a function (vm-menubar-buttons-possible-p) in
> vm-version, which you can use to distinguish between the cases.
>
> > While I will see what can be done, I think "punishing all the other
> users" is
> > a little strong. We are over complicating matters for very little gain
> IMO. At
> > least two of the possible toolkits (soon to be three with GTK3+) don't
> work,
> > we know two that will and then another 2 or more we have no idea about.
>
> I am not sure which toolkits you are talking about here. Can you be
> more specific?
>
> GTK2, GTK3 and whatever the toolkit used in the NS port (Mac?)

> > Moving this functionality to use a sub-menu is not a drastic change
> really. At
> > least then we would have the same code base and same interface on all
> > platforms. The argument to keep top-level action items/buttons would
> perhaps
> > have more weight if we were referring to a frequently used operation.
>
> Yes, for anybody that uses the menubar, these two buttons would be
> among the most frequently used ones. That is why they were made
> buttons originally.
>
>
So, what operations is it that people need frequently that require the emacs
menubar? I can see that maybe a menubar user may want the edit and possibly
the buffer menus, but the rest? If VM users need to switch to the emacs menu
frequently, I'd argue that what should happen is VM should not disable those
menu items and have them in the menubar - this would be much more convenient
that having to frequently toggle the whole menu-bar.

Tim

Tim Cross writes:

> So, what operations is it that people need frequently that require the emacs
> menubar? I can see that maybe a menubar user may want the edit and possibly
> the buffer menus, but the rest?

Oh, anything really. The whole point of using a mail client inside
Emacs is to have the power of Emacs for doing all the other things.
Some of the frequent things I needed do were to browse files or
directories, run shells etc. (I don't use the menubar much now, but I
used it a lot when I had RSI and did things by speech.)

> If VM users need to switch to the emacs menu
> frequently, I'd argue that what should happen is VM should not disable those
> menu items and have them in the menubar - this would be much more convenient
> that having to frequently toggle the whole menu-bar.

I agree, but that is too large a project to contemplate right now.
The whole menubar has to be rethought. But, our first task is to
restore VM to its original form. As I said, GTK users can have the
work-around, but there is no reason for all the other users to put up
with this overhead.

Cheers,
Uday

On Fri, Mar 4, 2011 at 5:43 AM, Uday S Reddy <email address hidden>wrote:

> Dear Tim, I have added a function (vm-menubar-buttons-possible-p) in
> vm-version, which you can use to distinguish between the cases.
>
> Hi Uday,

I notice from your definition of the above predicate that you test for gtk
for the Xemacs build as well. Does xemacs build with gtk? I'm trying to sort
out exactly what needs to be changed. The xemacs menu stuff is very
different to the emacs menu setup and I don't know if we need to also modify
the menu definitions for xemacs to handle gtk and non-gtk.

Tim

Tim Cross writes:

> I notice from your definition of the above predicate that you test for gtk
> for the Xemacs build as well. Does xemacs build with gtk? I'm trying to sort
> out exactly what needs to be changed. The xemacs menu stuff is very
> different to the emacs menu setup and I don't know if we need to also modify
> the menu definitions for xemacs to handle gtk and non-gtk.

I don't know. Since the limitation is in the GUI toolkit, I presumed
that XEmacs might have the problem as well. We will know for sure if
you can install XEmacs and test it. I don't have access to a machine
running GTK.

We can leave it out for now if you find it too much work. But it is
probably best to be done with it once and for all, and instead of
having to come back to it later.

Cheers,
Uday

On Fri, Mar 4, 2011 at 11:10 AM, Uday S Reddy <email address hidden>wrote:

> Tim Cross writes:
>
> > I notice from your definition of the above predicate that you test for
> gtk
> > for the Xemacs build as well. Does xemacs build with gtk? I'm trying to
> sort
> > out exactly what needs to be changed. The xemacs menu stuff is very
> > different to the emacs menu setup and I don't know if we need to also
> modify
> > the menu definitions for xemacs to handle gtk and non-gtk.
>
> I don't know. Since the limitation is in the GUI toolkit, I presumed
> that XEmacs might have the problem as well. We will know for sure if
> you can install XEmacs and test it. I don't have access to a machine
> running GTK.
>
> We can leave it out for now if you find it too much work. But it is
> probably best to be done with it once and for all, and instead of
> having to come back to it later.
>
> Uday,
>

as there is a job to restore the [undo] item to the menu, can I suggest that
instead, we just remove the single line that disables/undefines the standard
emacs edit menu? This will give us back the standard emacs undo, plus add
cut/paste, search, etc. Seems this would be more useful to manu users than
just a single operation and would likely fit in with what they are
accustomed to.

_______________________________________________
> Mailing list: https://launchpad.net/~vm
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~vm
> More help : https://help.launchpad.net/ListHelp
>

Tim Cross writes:

> as there is a job to restore the [undo] item to the menu, can I suggest that
> instead, we just remove the single line that disables/undefines the standard
> emacs edit menu? This will give us back the standard emacs undo, plus add
> cut/paste, search, etc. Seems this would be more useful to manu users than
> just a single operation and would likely fit in with what they are
> accustomed to.

It looks like you really don't want to do what I have proposed. Why
don't you just commit whatever you think is best and sign off, and I
will take care of the rest?

The reason I have been asking you to do it is so that you have the
commits and the credit for yourself. The work that you have done in
understanding the issue is very valuable. But, without doing commits,
you won't have anything to show for it.

Cheers,
Uday

On Fri, Mar 4, 2011 at 8:24 PM, Uday S Reddy <email address hidden>wrote:

> Tim Cross writes:
>
> > as there is a job to restore the [undo] item to the menu, can I suggest
> that
> > instead, we just remove the single line that disables/undefines the
> standard
> > emacs edit menu? This will give us back the standard emacs undo, plus add
> > cut/paste, search, etc. Seems this would be more useful to manu users
> than
> > just a single operation and would likely fit in with what they are
> > accustomed to.
>
> It looks like you really don't want to do what I have proposed. Why
> don't you just commit whatever you think is best and sign off, and I
> will take care of the rest?
>
> So, your proposals are not up for discussion/suggestions? If thats the
case, fine. I thought/hoped things were more of a collaboration and was
only trying to get clarification and understand the scope. Your response is
a surprise since this is the first time I've even raised this particular
aspect of the request to restore the [undo] option and have previously
stated I would do the other changes, despite my difference in opinion.

> The reason I have been asking you to do it is so that you have the
> commits and the credit for yourself. The work that you have done in
> understanding the issue is very valuable. But, without doing commits,
> you won't have anything to show for it.
>

From my position, there is not just an issue here - we have a number of
separate issues all relating to the same area i.e. menu bars. There are
numerous complexities here and some things only become evident once you
start to implement/solve these issues. Rather than just blindly going ahead
and doing what I think is the right solution, I thought it was better to
bounce ideas off you and others, increasing the likelihood the work done
will be acceptable.

So, what was your opinion wrt my suggestion? Rather than using up menu-bar
space with just an [undo] button/menu, would it be better to just restore
the standard emacs 'Edit' menu, which has a familiar format, includes the
standard emacs undo and would also add copy/cut/paste, search, etc?

Tim

> _______________________________________________
>

Have pushed up changes to add emacs and undo menus. Have defined them so that they are buttons under tookits that support them an menus when top-level buttons are not supported. Have tried to make it modular, but this is not easy due to the way most of the menus are defined using easymenu.el. Looks like this is probably why the menu 'buttons' were removed in the first place. Adding the additional complexity of working one way under some toolkits and another under others really requires a re-working of this code. Have not done anything with the xemacs menus.

Branch is ~tcross/vm/605799-3

Tim Cross writes:

> So, your proposals are not up for discussion/suggestions?

Sure they are up for discussion, but I think we had done enough of
that for the [Emacs] button. Now it is time to get it done. I didn't
hear you say that you have agreed to restore the [Emacs] button. I
thought you were still arguing why it shouldn't be done.

As for replacing the [undo] button by the Emacs Edit menu, it is not a
solution because the undo in the Edit menu is not vm-undo.

I am taking a look at your changes now.

Cheers,
Uday