Karmic: emacs22-gtk generated menus do not update (GTK only)

There seems to be an error message "<print> is undefined" in the minibuffer. Could you M-: (setq debug-on-error t) and post the contents of the resulting *Backtrace* buffer here, provided one is produced? Thanks.

I am setting the Status of this bug report to Incomplete to mark it as pending on your input. Once you supply the requested information, it can be changed back to New.

Sorry, that did not come out so good. In more detail, after you enable debug-on-error, try to visit a C buffer and attempt to open the C menu; this (I speculate) ought to produce a *Backtrace* buffer which you can save to a temporary file and attach here. (Press q in the *Backtrace* buffer to discard it. M-: (setq debug-on-error nil) to turn off debugging.) Sorry for the sloppy instructions, and thanks in advance.

Unless I'm missing something, there appears to be no backtrace. Next steps? Can anyone reproduce?

Bug #415298 alleges that this is a GTK problem. Can you check if the menus work if you run "emacs -nw"?

Ahh. I'm impressed you dug that up and it does sound similar.
I tried 'emacs -nw' and the menus do work that way.
Interestingly, if Mouse-1 on the major mode name in the mode line pops up the same GTK menu I expect from the menubar, so the menu itself functions but seems not to be attached to the menu bar properly.

Marking #415298 as a duplicate of this.
Is there anything further I can do to provide debugging help?

I would confirm this based on the duplicate, but I'm not altogether sure the problem is in Emacs. Can you check from your dpkg install logs which gtk components have been upgraded recently?

Reproduced on Karmic alpha 3 out of the box. Enable universe, install emacs22-gtk, edit /tmp/randomfile.c

Just to keep things in one place, note that duplicate bug #415298 reports this for the LaTeX menu as well. I guess it affects all dynamically added menus.

Bernhard: are you certain the problem is in Emacs, and not in e.g. some part of GTK? (See comment #8)

You mean because I confirmed? Erm...
We should definitely ask some GTK people. I thought about it, but couldn't find any good gtk package to file against. Please feel free to file against something else.

Reproduced the bug on Jaunty (clean install + all avail. updates on 26 Aug 09).
Org-menu and C++ menu don't work in emacs22-gtk and emacs-snapshot-gtk.

OK, I posted this on Bugzilla as http://bugzilla.gnome.org/show_bug.cgi?id=593202
Feel free to drop by over there.

Redirecting GNU Emacs bug tracker; adding a new tracker for the Gnome bug (assigned to gtk+)

@mortajfrondoj: I am unable to repro on my production Jaunty box. Do you have backports, proposed-updates, etc selected in your Apt sources?

I can confirm the bug (on karmic), only that it is unlikely that it should be assigned to emacs.
I have reproduced the problem with emacs-snapshot-gtk (karmic), emacs23-gtk (compiled from debian source packages) and the FSF sanctioned vanilla tarballs of emacs23.
In all those cases the X toolkit version works fine.

Like the upstream Emacs bug alleges, I can confirm that this also affects the Buffers menu. I also discovered that tearing off the Buffers menu and switching to another buffer is a workaround -- it will cause not only the Buffers menu, but also the C menu to finally update.

Tearing off the Tools menu would sometimes, but not always, also work as a workaround. Tearing off other menus did not help. I speculate that the Tools menu is also partially dynamic, and that I did something to cause it to be updated when I did see that tearing it off caused the C and Buffers menus to be brought up to date.

I have still been unable to reproduce on Jaunty. I tried with the jaunty-proposed repository enabled, and finally both jaunty-proposed and jaunty-backports, and it still did not repro. I am speculating that mortajfrondoj did not have a vanilla Jaunty (Ubuntu 9.04) system.

Furthermore, since Karmic (I used 9.10 alpha 4) has the same version of emacs22 as Jaunty, it does seem that the root cause is in some GTK component which has changed between Jaunty (Gnome 2.26) and Karmic (2.28?). In any event, Emacs should work regardless of the GTK version, so perhaps it would still make sense to try to fix the problem in Emacs.

The Emacs upstream bug now has a patch. It is for Emacs 23 and probably needs further work to be adapted for older versions of GTK and Emacs 22.

Since Mortaj is not responding, I will speculate that he actually meant "Karmic". He talked about "all updates from Aug 26", which would make less sense for Jaunty, since there were no no relevant updates for these packages after Jaunty release.

For the benefit of users who are unfamiliar with GTK tearable menus, here is a screen shot. Pull down the menu and select the "tearline" just below the menu title. This will result in the menu being detached into a floating window where you can see the menu's contents all the time.

@Bernhard: yeah, that's what I really think he (?) meant, too.

This appears to be the commit that fixes this for emacs23. It is not a terribly complex fix so patching Ubuntu's 22 may not be too hard.

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3715ffe3e3b2c64d113bf26d94aab559f8559e83

The quick workaround mentioned in the above linked bug reports is to start emacs with GDK_NATIVE_WINDOWS=1 which I can confirm fixes the dynamic menu problems, at least for python-mode.

to #13: sorry, it wasn't working only with global-menu-applet 0.7.5 and mac4lin metacity theme on Jaunty. When I disablet global menu, it worked.

@Thomas E Jenkins: Thanks for the GDK_NATIVE_WINDOWS=1 workaround, I can confirm it fixes the problem for the Edit menu, Python-mode, SCLang-mode and Org-mode.

I found the same problem with the Emacs 23 packages from Debian Sid.

ii emacs23 23.1+1-4
ii emacs23-bin-common 23.1+1-4
ii emacs23-common 23.1+1-4

But Emacs 23 in Fedora 11 Updates has not this problem.

I can confirm the same problem with the emacs23 package in an up-to-date install of Ubuntu Karmic beta. The GDK_NATIVE_WINDOWS=1 workaround also works. It seems the upstream patch would have to be applied to Ubuntu's emacs23, as well.

Yes, I can also confirm it as well on emacs23 23.1+1-4ubuntu3 . Also the workaround of tearing off the Buffers menu and switching buffers seems to work for me (such a relief to have AUCTeX menus again! ugh!)

Works for me in emacs-snapshot but not in emacs23, so I changed the status there.

The menus work great with emacs-snapshot, but they don't with emacs23.

OK, more data to add to the confusion.

* With emacs23-gtk, set up a mode that has a custom menu (e.g. shell script, HTML Helper). Then start the calendar (M-x calendar). Starting in the non-calendar window, watch what happens to the custom menus. On system A:

** The edit menu does not work.

** The custom menu doesn't work at all. Now toggle between the two (C-x o).

** None of the custom menus work. Toggle back (C-x o again).

** None of the custom menus work.

* On system B, as above:

** The Edit menu works.

** The custom menu works. Now toggle between the two (C-x o).

** None of the custom menus work, except the Scroll menu. Except that produces what should be the shell script mode menu (!). Note that the Edit menu is removed (This is normal; Emacs 22.2.1 on Jaunty does the same). Toggle back (C-x o again).

** The custom menu works. The edit menu fails to work.

System A is a Lenovo r51 laptop with a radeon video gpu (http://www.charlescurley.com/Lenovo.R51.html).

System B is a Fit-PC 1 (http://www.fit-pc.com/fit-pc1/fit-pc-1-0-specifications.html).

Clearly the different video cards make the drivers suspect here.

It also occurs to me that calendar mode and its menus have been around a lot longer than shell-script mode's menu (22.2.1 has a different custom menu). So are there two different ways to initialize a custom menu, one of which isn't working correctly in the gtk version?

Of the two suspicions, I am inclined toward the second. I can't see emacs reaching down far enough such that the driver code would make a difference.

This bug is still present in official Karmic release (I just now upgraded to it), both with emacs22-gtk and emacs23.

bjd

I have also observed this with emacs23. As a workaround: activate the menu with F10 and move with your cursor keys to the 'empty' menus. for me, this always brings the correct entries.

For Emacs 23, this problem was solved by the latest Debian package emacs23 (23.1+1-5) .

Cheese, thanks for this hint. I've added a bug remote to the debian bug.

Maybe this patch is a candidate for an SRU if it can be backported to emacs22.

This bug was fixed in the package emacs23 - 23.1+1-4ubuntu5

---------------
emacs23 (23.1+1-4ubuntu5) lucid; urgency=low

  [ Rob Browning ]
  * Apply upstream patch to fix problem with GTK and dynamically
    generated menus (which could be unexpectedly empty). Thanks to
    Baylis Shanks <email address hidden> for the report.
    (closes: 550541)

  [ Reinhard Tartler ]
  * snatched patch from debian upload 23.1+1-5. LP: #415101
 -- Reinhard Tartler <email address hidden> Fri, 06 Nov 2009 09:21:16 +0100

This bug was fixed in the package emacs22 - 22.2-0ubuntu8

---------------
emacs22 (22.2-0ubuntu8) lucid; urgency=low

  * backport patch from emacs23 to ensure that dynamic menus get updated properly
    Closes: #550541, LP: #415101
 -- Reinhard Tartler <email address hidden> Fri, 06 Nov 2009 11:14:23 +0100

the patch seems to work for me for emacs23 in lucid. I've just uploaded a new emacs22 to lucid with a backported patch of this (it needed some manual adaptation), let's see how it works out.

If this works out well, I can see to SRU this for karmic.

Is there a karmic ppa that contains the fix? I still have the old packages in karmic.

Bernhard <email address hidden> writes:

> Is there a karmic ppa that contains the fix? I still have the old
> packages in karmic.

It seems the patch works, so I think I can continue directly with
uploading to karmic-proposed

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

both uploaded to karmic-proposed, waiting approval by ubuntu-sru and publishing

Waiting for motu-sru ack for emacs23 package (which is in universe).

Accepted emacs22 into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

motu-sru ACK for emacs23 package.

Accepted emacs23 into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I just tried emacs23 with the new fix and it works for me now. Thx!

Thanks for testing! Any chance to test the emacs22 update as well?

OK, didn't use emacs22 for quite a while now. But just installed it from karmic-proposed and the dynamic menus (Latex in my case) seem to work fine there.

=== Test procedure ===
1. Start emacs23 (without arguments).
2. Open a new file test.c in emacs: C-x C-f test.c RET

When I first executed the test procedure I got an empty C menu.

Then I upgraded emacs23 to karmic-proposed and repeated the test procedure. Now I got the correct C menu.

So I suppose that we can conclude that #415101 is solved for emacs23.

W00T!! I can confirm that this solves the missing menu problem as I described in comment 30 above.

Thank you all.

Charles Curley <email address hidden> writes:

> W00T!! I can confirm that this solves the missing menu problem as I
> described in comment 30 above.

Can someone else than me confirm as well that the fix works with emacs22
*as well*?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

@reinhard: I also confirmed that in #47.

This bug was fixed in the package emacs22 - 22.2-0ubuntu6.1

---------------
emacs22 (22.2-0ubuntu6.1) karmic-proposed; urgency=low

  * backport patch from emacs23 to ensure that dynamic menus get updated properly
    Closes: #550541, LP: #415101
 -- Reinhard Tartler <email address hidden> Mon, 09 Nov 2009 12:03:17 +0100

This bug was fixed in the package emacs23 - 23.1+1-4ubuntu3.1

---------------
emacs23 (23.1+1-4ubuntu3.1) karmic-proposed; urgency=low

  [ Rob Browning ]
  * Apply upstream patch to fix problem with GTK and dynamically
    generated menus (which could be unexpectedly empty). Thanks to
    Baylis Shanks <email address hidden> for the report.
    (closes: 550541)

  [ Reinhard Tartler ]
  * snatched patch from debian upload 23.1+1-5. LP: #415101
 -- Reinhard Tartler <email address hidden> Mon, 09 Nov 2009 12:09:13 +0100

I have this bug in emacs 23.1+1-4ubuntu7 NOT FIXED

Hassan: could you please post a screenshot, to make sure it's really the same issue? Thanks.

Since you only mention that the bug is present in -4ubuntu7, I assume the karmic SRU does fix it and that the there has been a regression in later versions.

I'm sorry. It was a problem with global menu applet, but same as explained here!
sorry again

I'm a bit confused about the status of this bug. I'm running Maverick (last updated earlier today) and I'm seeing this bug in emacs 23.1+1-4ubuntu7. Is this a regression or is it simply that the proper update hasn't reached me as yet?

Martin Soto: 23.1+1-4ubuntu7 is the newest. According to the Changelog, the fix was in 23.1+1-4ubuntu5 (so Ubuntu version 5, where you are now at version 7). On the system where you have installed Emacs, you can view the Changelog in /usr/share/doc/emacs23/changelog.Debian.gz (it's for Ubuntu as well as Debian, despite the name).

I don't have this problem with 23.1+1-4ubuntu7 in maverick. My dynamic Latex menus show fine. Martin, could you please post a screenshot to make sure we talk about the same issue?

I am also experiencing this bug on Maverick, now the final release version. The workaround with setting GDK_NATIVE_WINDOWS=1 does not help. However, opening the menu with F10 shows the correct menus.

I just repeated the test I described in comment #30 above, and did not see this problem. Both machines are running emacs23 23.1+1-4ubuntu7 i386. Machine A is running Lucid, B Maverick.

This bugs also affect me on a system running Maverick. AUCTEX menus (Command and Ref) is affected. Using the GDK_NATIVE_WINDOWS=1 workaround will make the menus work correctly for a moment, less than 30 seconds, but will then disappear. Using the F10 key workaround if working.

I experience this problem in Maverick.

$ apt-cache policy emacs
emacs:
  Installed: 23.1+1-4ubuntu7
  Candidate: 23.1+1-4ubuntu7
  Version table:
 *** 23.1+1-4ubuntu7 0
        500 http://us.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages
        100 /var/lib/dpkg/status

I've tried GDK_NATIVE_WINDOWS but it did not help. (Yes, I checked with M-x getenv that the variable was set.)

Hitting F10 or using M-x accelerate-menu does the trick.

I can confirm that this bug is still present in Maverick with all provided emacs flavours (22,23, snapshot). The GDK_NATIVE_WINDOWS=1 trick does not work either. It once worked with karmic, though.

Pressing F10 also works for me.

This seems to be a new bug with similar symptoms. I've reported it as bug 673302 - it seems to be related to appmenu-gtk.

Krzysztof: thanks man, #673302 fixed it.

I checked bug 673302 and indeed that is the bug I am experiencing. Same symptoms, different cause. Thanks Krzysztof.

I would like to confirm that this bug still persists on Ubuntu 11.10, with emacs23 as it comes "out of the box" (and "apt-get install emacs23" says that I have the most recent version).

No matter how many files I open, the "Buffers" menu in the menu bar is never updated; it only shows 1 file (the very first one) and various "junk" buffers (*About*, *scratch*, *messages* etc). It never shows any buffers with actual files other than the very 1st one.

On the other hand, the menu that pops up upon Ctrl + left mouse button is correct.

Status changed to 'Confirmed' because the bug affects multiple users.

this bug still persists on ubuntu 12.10, with emacs24.

the "buffers" menu in the menu bar is never updated.

On the other hand, the menu that pops up upon Ctrl + left mouse button is correct.

karmic has seen the end of its life and is no longer receiving any updates. Marking the karmic task for this ticket as "Won't Fix".

Status changed to 'Confirmed' because the bug affects multiple users.

This bug still affects Ubuntu 18.04 LTS with emacs-25 package, when running the Unity
desktop. In particular editing lisp files and using slime is next to impossible. I have found
a fix:

For emacs launched from a terminal window simply add
export UBUNTU_MENU_PROXY=emacs
to .bashrc

For emacs launched from clicking on icons, i have modified the exec line of
/usr/share/applications/emacs25.desktop to the following:

Exec=/usr/bin/emacs %F

instead of emacs25 because then the mechanism that puts the menu at the top of the screen is inhibited. In both cases the menu bar is confined to the emacs windows and then works OK.