Re: XEmacs 21.5 and dired-gets-current-buffer-wrong bug
Mats Lidell <matsl(a)xemacs.org> writes:
Under XEmacs 21.5 dired sometimes gets the idea that the current
buffer actually is the *dired* buffer. This doesn't seem to happen
when running in '-vanilla'-mode. This could point in the direction of
some e-lisp-package doing bad things. Unfortunately it doesn't seem to
happen under 21.4.
Now this could seem like an innocent thing but after this has happened
XEmacs becomes very hard to work with. Example:
1. Create a buffer: /tmp/HI
2. Insert one line: hi
3. Buffer looks like
-------
hi
-------
4. Do dired-jump-back (C-x C-j). Buffer now looks like.
-------
/tmp:
hi
-------
And the error message: "dired-subdir-alist seems to be mangled" is
displayed. I guess the error message is because the buffer that dired
thinks is the dired buffer actually is the buffer I'm editing and thus
doesn't look like how a dired buffer should look like.
This is just one example of how it can be. Since obviously something
is badly broken very strange things can happen. Problems occur when
saving files or doing other operations that might involve dired
operations.
I have tried to debug this in e-lisp but I have failed. I need a good
debug idea. Anyone who has an idea how to track this down?
Yours
--
%% Mats
Wow, so someone else has seen this too.
I first ran into this in 21.5.20 (ref: m37jiop84i.fsf(a)uh-oh.nvidia.com)
It seemed to be triggered by lazy-lock but I couldn't figure out
why. Eventually I tracked it down enough to generate the patch
below which avoided the problem without ever figuring out what
was really happening.
However, it seems to have been magically fixed in a recent
version 21.5 since I haven't needed to use the patch since at
least 21.5.24, and I've re-enabled lazy-lock (but with
lazy-lock-minimum-size increased from 10k to 50k).
Anyway, here's the patch. Maybe it will help you figure out
what's really going on.
*** process.el 2005/09/27 14:31:17 1.1
--- process.el 2005/09/27 14:33:37
***************
*** 133,139 ****
with SIGINT, then with SIGKILL if you quit again before the process exits.
Coding systems for the process are the same as for `start-process-internal'."
! (let (proc inbuf errbuf kill-inbuf kill-errbuf no-wait start end)
;; first set up an unwind-protect to clean everything up. this will:
;;
;; -- kill the process. (when we're not waiting for it to finish, we
--- 133,139 ----
with SIGINT, then with SIGKILL if you quit again before the process exits.
Coding systems for the process are the same as for `start-process-internal'."
! (let (curbuf proc inbuf errbuf kill-inbuf kill-errbuf no-wait start end)
;; first set up an unwind-protect to clean everything up. this will:
;;
;; -- kill the process. (when we're not waiting for it to finish, we
***************
*** 145,150 ****
--- 145,155 ----
;;
;; note that we need to be *very* careful in this code to handle C-g
;; at any point.
+
+ ;; save the current buffer for restore on exit in unwind sequence at bottom
+ ;; tbennett(a)nvidia.com 9/27/05
+ (setq curbuf (current-buffer))
+
(unwind-protect
(progn
;; first handle INFILE.
***************
*** 313,318 ****
--- 318,327 ----
;; outer unwind-protect forms, to make sure we always clean up.
(if (and inbuf kill-inbuf) (kill-buffer inbuf))
(if (and errbuf kill-errbuf) (kill-buffer errbuf))
+
+ ;; restore orig buffer. sometimes changed for reasons unclear to me...
+ (set-buffer curbuf)
+
(condition-case nil
(if (and proc (process-live-p proc)) (kill-process proc))
(error nil)))))
--
--tony