Red Hat Bugzilla – Bug 610082
If xemacs is running an external application on quit a useless menu appears
Last modified: 2010-09-27 23:17:43 EDT
Created attachment 428448 [details] A short LaTeX file for testing Description of problem: Running xemacs on some LaTeX file, compiling it to PDF (PDFLaTeX mode), and then viewing it opens the PDF in xpdf (same if you try the xdvi preview). Tring to quit xemacs via the X button opens a dialog asking "Active processes exist; kill them and exit anyway?" with 4 buttons (Yes, No, <blank>, Cancel), none of which does anything. Version-Release number of selected component (if applicable): xemacs-21.5.29-12.fc14.x86_64 How reproducible: Always Steps to Reproduce: 1. xemacs hello.tex # Attached file 2. C-c C-c # Until getting to "View" 3. Try to quit via the window's X button Actual results: Useless dialog described above Expected results: Active dialog, allow to kill and exit or cancel and go back. Additional info: The dialog is quite dumb. What do "Yes", "No", and "Cancel" mean here? "Yes" is kill and exit (that I've used when it used to work ;-), "No" means don't kill and don't exit (ditto). But "Cancel"? And the blank button?
The "blank" button is just a spacer. It isn't supposed to do anything. Somebody at some time in the remote past apparently thought it looked good. I agree with you, though; it looks like a button. I can't reproduce your other problems, though. Using the recipe you provided above, "Yes" kills and exits, "No" means don't kill and don't exit, and "Cancel" means "Close this dialog and pretend I didn't try to exit" (which has the same effect as "No"). If you want the blank removed, or for someone to rethink having both "No" and "Cancel" on that dialog, upstream developer attention will be required. Please send a request to xemacs-beta@xemacs.org. Let's try to figure out why the buttons aren't working for you. Would you mind listing the results of "rpm -qa | grep -F xemacs | sort"? Also, do you get the same behavior if you run "xemacs -vanilla"?
OK, I'll focus on the "buutons not working" bug, the others are cosmetic. Just upgraded xemacs, same behaviour. xemacs-21.5.29-13.fc14.x86_64 xemacs-common-21.5.29-13.fc14.x86_64 xemacs-info-21.5.29-13.fc14.noarch xemacs-packages-base-20090217-4.fc12.noarch xemacs-packages-extra-20090217-7.fc13.noarch xemacs-packages-extra-info-20090217-7.fc13.noarch Same with "xemacs -vanilla", just that a buffer telling me what is running shows up.
Dumb question: I looked at the changelog, and saw mention of the "xemacs-xft" package. Is that one supposed to replace plain "xemacs", should it be installed alongside "xemacs", ...?
Hmmmmm, and I'm on an x86_64 as well. Ah, but you filed this against Rawhide. I'm using F-13. I'll have to see if this is due to something changing in Rawhide. Unfortunately, I'm leaving on a trip first thing in the morning, and I'll be gone for about a week and a half. I'm sorry to leave this unresolved, but I will have only spotty Internet connectivity while I'm gone. The xemacs-xft package can be installed alongside the xemacs package. It contains a new binary, "xemacs-xft", which is Xft- and fontconfig-enabled. I made that because of multiple user requests for it, not because I think it is a good idea. :-) The Xft support is still a bit shaky. You can use alternatives to make xemacs-xft be /usr/bin/xemacs, if you so desire.
OK, if you think xemacs-xft is a bad idea, I'll heed your advise. Don't worry about this minor annoyance, and enjoy your trip. BTW, this has been this way for quite some time, I just didn't get around to "bug reporting mode" for some time. Should report immediately, sorry.
Just found out that it seems to do the same each time it opens a dialog. E.g.: $ xemacs -vanilla /tmp/xyz & # Write something in xyz's buffer, _don't_ save # Close xemacs via X on window dressing The result is a menu, and pressing "Yes" for "Save file xyz" has no effect whatsoever. Ditto for the other options offered.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Using the recipe in comment 6, I get /tmp/xyz written out, on both F-13 and Rawhide. Hmmmm. There must be something different in our environments that is making it fail for you. Would you mind sharing your LANG or LC_* environment variable settings? If that doesn't turn anything up, maybe I'll have you strace the xemacs process so we can see if some operation is failing.
Now I have: xemacs-21.5.29-13.fc14.x86_64 xemacs-common-21.5.29-13.fc14.x86_64 xemacs-info-21.5.29-13.fc14.noarch xemacs-packages-base-20100727-1.fc15.noarch xemacs-packages-extra-20100727-1.fc15.noarch xemacs-packages-extra-info-20100727-1.fc15.noarch OK, let's see... $ env | grep 'LANG\|LC_' LANG=en_US.utf8 GDM_LANG=en_US.utf8
Created attachment 438843 [details] The requested strace output What I did: strace xemacs /tmp/tst 2> /tmp/xemacs.trace & Wrote some nonsense into the file Tried to close via X on window, menu shows up. Click on "Yes", nothing. Click on "Cancel", nothing. Close menu via its X Exit xemacs via ctrl-X ctrl-C
I'm afraid I didn't learn anything from that strace. :-( I thought about having you use ltrace to see if something funny is going on in the X layer, but my attempt to use ltrace on XEmacs resulted in a permanently hung XEmacs. So... Can you try this for me? I want to see if we can eliminate X from the equation. xemacs /tmp/tst & Write some nonsense into the file. M-: (save-some-buffers) Type "y". Does that save the file?
The elisp expression returns t, and the nonsense is saved this time. And yes, "ltrace xemacs /tmp/tst" goes into some kind of loop :-(
So rather than eliminate X, you fingered it as the culprit. Do you have a .Xresources or .Xdefaults file with XEmacs or Emacs entries?
No such files around here,
Now it went away... but running under XFCE (Gnome is totally hosed right now).
I've been struggling with the Gnome breakage on Rawhide myself. Well, let's wait a little while then and see if the problem comes back once Gnome is usable again.
Now Gnome woks here. And the bug stays gone.
Excellent! I haven't had time to play with Rawhide for a few days, so the fact that Gnome now works is good news, too. :-) OK, then I'll close this bug. Please reopen it if the bug reappears.