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

[Randall Leeds]

Emacs has a pretty non-standard way of using GTK that makes some assumptions about GTK internals. These have been broken with gtk 2.18.

Symptoms: Dynamic menus are no longer updated if klicked on with the mouse. They are updated if the menu is opened with F10.

Steps to reproduce:
 - Install e.g. auctex and open a .tex file in Latex mode.
 - Klick on the menu bar and see the an empty menu.

Expected result:
 - a non-empty menu.

Original Report:

Subject: Emacs language menus are blank

Binary package hint: emacs22

The attached picture should say it all.
I have tested C/C++, Python, Erlang and they all show up blank.
I've had this problem for a while not (a month or so, maybe?), but I'm not sure exactly when it showed up. I suspected it was just me for a while, but I've tested with blank ~/.emacs.d directory for defaults as well.

ProblemType: Bug
Architecture: amd64
Date: Tue Aug 18 00:34:54 2009
DistroRelease: Ubuntu 9.10
Package: emacs22-gtk 22.2-0ubuntu2
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-5.24-generic
SourcePackage: emacs22
Uname: Linux 2.6.31-5-generic x86_64

[era (era)]

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.

[era (era)]

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.

[Randall Leeds (randall-leeds)]

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

[era (era)]

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

[Randall Leeds (randall-leeds)]

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.

[Randall Leeds (randall-leeds)]

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

[era (era)]

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?

[era (era)]

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

[era (era)]

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.

[era (era)]

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

[Bernhard (b.a.koenig)]

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.

[Mortaj Frondoj (mortajfrondoj)]

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.

[Bernhard (b.a.koenig)]

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

[era (era)]

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

[era (era)]

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

[Gianluca Della Vedova (gianluca-dellavedova)]

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.

[era (era)]

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.

[era (era)]

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.

[Bernhard (b.a.koenig)]

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.

[era (era)]

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.

[Thomas E Jenkins (thomas-jenkins)]

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.

[Mortaj Frondoj (mortajfrondoj)]

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.

[Aymeric Mansoux (aymeric)]

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

[Robin Lee (cheeselee)]

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.

[schalkpd (schalkpd+launchpad)]

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.

[David Huggins-Daines (dhuggins)]

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!)

[Bernhard (b.a.koenig)]

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

[Igor Wojnicki (wojnicki)]

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

[Charles Curley (charlescurley)]

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.

[bjd (bjd-xs4all)]

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

bjd

[Reinhard Tartler (siretart)]

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.

[Robin Lee (cheeselee)]

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

[Reinhard Tartler (siretart)]

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.

[Launchpad Janitor (janitor)]

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

[Launchpad Janitor (janitor)]

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

[Reinhard Tartler (siretart)]

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.

[Bernhard (b.a.koenig)]

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

[Reinhard Tartler (siretart)]

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

[Reinhard Tartler (siretart)]

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

[Martin Pitt (pitti)]

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

[Martin Pitt (pitti)]

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!

[Devid Antonio Filoni (d.filoni)]

motu-sru ACK for emacs23 package.

[Martin Pitt (pitti)]

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!

[Bernhard (b.a.koenig)]

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

[Martin Pitt (pitti)]

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

[Bernhard (b.a.koenig)]

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.

[Kenneth Pålsson (palsson-kenneth)]

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

[Charles Curley (charlescurley)]

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

Thank you all.

[Reinhard Tartler (siretart)]

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

[Bernhard (b.a.koenig)]

@reinhard: I also confirmed that in #47.

[Launchpad Janitor (janitor)]

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

[Launchpad Janitor (janitor)]

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

[Hassan (hsn-zamani)]

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

[Bernhard (b.a.koenig)]

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

[Steve Langasek (vorlon)]

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.

[Hassan (hsn-zamani)]

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

[Martin Soto (soto255)]

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?

[era (era)]

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

[Bernhard (b.a.koenig)]

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?

[Alexander Hunziker (alex-hunziker)]

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.

[Charles Curley (charlescurley)]

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.

[gronbaek (gronbaek)]

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.

[Louis-Dominique Dubeau (ldd)]

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.

[hpdoerr (doerr-kis-deactivatedaccount)]

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.

[Krzysztof Klimonda (kklimonda)]

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.

[hpdoerr (doerr-kis-deactivatedaccount)]

Krzysztof: thanks man, #673302 fixed it.

[Louis-Dominique Dubeau (ldd)]

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

[Vladimir Menkov (vmenkov)]

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.

[Launchpad Janitor (janitor)]

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

[philipp sutter (sutter)]

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.

[Rolf Leggewie (r0lf)]

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

[Launchpad Janitor (janitor)]

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

[Michel Talon (talonmichel)]

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.