Bug 41976
Summary: | XEmacs can't be quitted after visiting an Info node below the root | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Reuben Thomas <rrt> |
Component: | xemacs | Assignee: | Jens Petersen <petersen> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Aaron Brown <abrown> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
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: | --- | Target Upstream Version: | |
Embargoed: |
Description
Reuben Thomas
2001-05-23 14:35:27 UTC
Exactly what error do you get? I have no problems here... 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! It still doesn't happen here (with a .emacs file containing only the lines above). 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 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). And the reason is that xemacs wants to save a .flc file to the info directory. Root can do this, other users can't. 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. 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. Reproduced still with xemacs-21.4.12. By the way, I recommend using lazy-lock-mode rather than fast-lock-mode. lazy-lock-mode works well for me. Closed following comment 8. Thanks. Actually, afaict this is fixed in 21.4.14 at least. |