Bug 610082 - If xemacs is running an external application on quit a useless menu appears
Summary: If xemacs is running an external application on quit a useless menu appears
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: xemacs
Version: rawhide
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
Assignee: Jerry James
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-01 14:23 UTC by Horst H. von Brand
Modified: 2010-09-28 03:17 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-09-28 03:17:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
A short LaTeX file for testing (192 bytes, text/plain)
2010-07-01 14:23 UTC, Horst H. von Brand
no flags Details
The requested strace output (2.44 MB, application/octet-stream)
2010-08-15 16:45 UTC, Horst H. von Brand
no flags Details

Description Horst H. von Brand 2010-07-01 14:23:56 UTC
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?

Comment 1 Jerry James 2010-07-06 17:48:40 UTC
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.

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

Comment 2 Horst H. von Brand 2010-07-07 20:28:07 UTC
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.

Comment 3 Horst H. von Brand 2010-07-07 20:34:46 UTC
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", ...?

Comment 4 Jerry James 2010-07-09 05:29:32 UTC
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.

Comment 5 Horst H. von Brand 2010-07-11 16:43:37 UTC
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.

Comment 6 Horst H. von Brand 2010-07-19 17:52:34 UTC
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.

Comment 7 Bug Zapper 2010-07-30 12:22:23 UTC
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

Comment 8 Jerry James 2010-08-04 18:48:27 UTC
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.

Comment 9 Horst H. von Brand 2010-08-15 16:41:13 UTC
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

Comment 10 Horst H. von Brand 2010-08-15 16:45:16 UTC
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

Comment 11 Jerry James 2010-08-23 19:34:31 UTC
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?

Comment 12 Horst H. von Brand 2010-08-31 14:06:36 UTC
The elisp expression returns t, and the nonsense is saved this time.

And yes, "ltrace xemacs /tmp/tst" goes into some kind of loop :-(

Comment 13 Jerry James 2010-09-01 03:09:40 UTC
So rather than eliminate X, you fingered it as the culprit.  Do you have a .Xresources or .Xdefaults file with XEmacs or Emacs entries?

Comment 14 Horst H. von Brand 2010-09-12 06:05:57 UTC
No such files around here,

Comment 15 Horst H. von Brand 2010-09-23 03:19:25 UTC
Now it went away... but running under XFCE (Gnome is totally hosed right now).

Comment 16 Jerry James 2010-09-24 02:34:08 UTC
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.

Comment 17 Horst H. von Brand 2010-09-27 21:47:26 UTC
Now Gnome woks here. And the bug stays gone.

Comment 18 Jerry James 2010-09-28 03:17:43 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.