Bug 41976 - XEmacs can't be quitted after visiting an Info node below the root
Summary: XEmacs can't be quitted after visiting an Info node below the root
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xemacs (Show other bugs)
(Show other bugs)
Version: 9
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-05-23 14:35 UTC by Reuben Thomas
Modified: 2007-04-18 16:33 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-06 01:07:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Reuben Thomas 2001-05-23 14:35:27 UTC
Description of Problem:
After visiting any info node other than the info directory, you can't quit XEmacs 
(except by killing the process),

How Reproducible:
Every time

Steps to Reproduce:
1. Start xemacs
2. Type C-h i to get into the info browser
3. Select any node
4. Type C-x C-c to quit Emacs.

Actual Results:

It won't quit at this stage, but gives an error.

Expected Results:

It should quit.

Additional Information:

Comment 1 Trond Eivind Glomsrxd 2001-05-23 14:39:16 UTC
Exactly what error do you get? I have no problems here...

Comment 2 Reuben Thomas 2001-05-23 14:58:34 UTC
I get "wrong argument type: stringp, nil"

I just found that I need the following minimal .emacs to get the problem:

(custom-set-variables
 '(fast-lock-mode t nil (fast-lock)))

This can be auto-generated from M-x customize fast-lock, by switching fast-lock
to on, so it's not just my elisp hackery!

Comment 3 Trond Eivind Glomsrxd 2001-05-23 15:14:29 UTC
It still doesn't happen here (with a .emacs file containing only the lines above).

Comment 4 Reuben Thomas 2001-05-23 15:22:39 UTC
Well, it happens to me with such a .emacs file (only those two lines) on two
different machines running RH 7.1. In case you're not copying me *exactly*, try:

1. Start XEmacs with the above .emacs file.
2. C-h i to start info
3. Visit the AUCTeX node (for me that's the first one in the menu).
4. Press C-x C-c.

That's what gets me the error I reported. If I remove the setting from my full
.emacs file, or start XEmacs without a .emacs file, I don't get the problem.

The exact xemacs packages and versions I have are:

xemacs{-info}-21.1.14-10

Comment 5 Trond Eivind Glomsrxd 2001-05-23 15:57:50 UTC
OK, I can reproduce it now. It doesn't happen for root...

Here is the traceback:

Signaling: (wrong-type-argument stringp nil)
  expand-file-name(nil)
  fast-lock-cache-name("~/.emacs-flc")
  fast-lock-save-cache(#<buffer "*info*">)
  mapcar(fast-lock-save-cache (#<buffer "*info*"> #<buffer "*scratch*"> #<buffer
" *Minibuf-0*"> #<buffer " *Echo Area*"> #<buffer " *pixmap conversion*">
#<buffer " *load*"> #<buffer " *Message-Log*"> #<buffer " *Info-tmp*"> #<buffer
" *info tag table*">))
  fast-lock-save-caches-before-kill-emacs()
  kill-emacs()
  save-buffers-kill-emacs(nil)
  call-interactively(save-buffers-kill-emacs)

I have reported the bug to the xemacs developers (M-x report-emacs-bug).

Comment 6 Trond Eivind Glomsrxd 2001-05-23 16:04:29 UTC
And the reason is that xemacs wants to save a .flc file to the info directory.
Root can do this, other users can't.

Comment 7 Reuben Thomas 2001-05-23 16:11:38 UTC
This is odd, as in my normal .emacs file, I also have the line

 '(fast-lock-cache-directories (quote ("~/.emacs-flc")))

in my customizations, so it shouldn't be trying to save into any other directory
in the first place.

Comment 8 Reuben Thomas 2001-09-05 14:49:36 UTC
I think I have found the cause of this problem (or at least another related
problem): when the hook is run to save the fast-lock cache, buffer-file-truename
is nil, so fast-lock can't construct the file name under which to save the
cache. Presumably buffer-file-truename wasn't nil when fast-lock mode was
originally entered (which is how it decides whether to use fast-lock or not).

I've reported the bug with this additional information to the XEmacs developers.

Comment 9 Jens Petersen 2003-05-19 11:58:47 UTC
Reproduced still with xemacs-21.4.12.

Comment 10 Jens Petersen 2003-05-19 12:36:05 UTC
By the way, I recommend using lazy-lock-mode rather than fast-lock-mode.
lazy-lock-mode works well for me.

Comment 11 Jens Petersen 2003-11-06 01:02:24 UTC
Closed following comment 8.  Thanks.

Comment 12 Jens Petersen 2003-11-06 01:07:08 UTC
Actually, afaict this is fixed in 21.4.14 at least.


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