[Bug: 21.5-b28] Problem with dired (C-x d)

[tony e. bennett]

Mats Lidell <matsl <at> xemacs.org> writes:

> 
> Michael Sperber writes:
> > Very odd: It seems it's trying to insert the directory list into
> > the *Buffer List* buffer.
> 
> This sounds like the same problem I have been seeing for years:
> 
> "http://calypso.tux.org/pipermail/xemacs-beta/2006-May/009236.html"
> 
> The idea that font locking could be involved let me then to go back to 
> good old slow font locking and by that I manage to keep the problem 
> away. But it resurfaced again a few months, maybe even half a year, ago. 
> So I guess the bug it is lurking inside somewhere.
> 
> > Could you trace the `dired-find-buffer-nocreate' function when it
> > happens, reproduce the problem, and post the output?  I.e.
> > 
> > M-x trace-function-backgroud RET
> > dired-find-buffer-nocreate RET
> > RET
> > 
> > and then post the contents of *trace-output*?

This sounds very much like a problem I reported back in May 2005
(below).   Altho the (set-buffer) seemed to fix it, the real fix was
to give up on lazy-lock.


  From: tbennett at nvidia.com
  Subject: Re: current buffer changed on return from call-process in 21.5.20
  Newsgroups: gmane.emacs.xemacs.beta
  Date: Mon, 02 May 2005 13:36:49 -0400


  tbennett at nvidia.com writes:

  > Yesterday I tried to switch from 21.5.18 to 21.5.20.  Compiled it
  > with no optimization and with all debug enabled:
  >
  >     ./configure --with-gcc --with-optimization --disable-database
--disable-sound --enable-error-checking=all --enable-debug
  >
  > On each find-file, XEmacs threw an error indicating "bad ispell
  > version".  Dired failed with something like "bad multi-alist".
  >
  > I had time to partially track down the ispell problem.  ispell is
  > invoked because I use flyspell on most writable files.  ispell's
  > function check-ispell-version (ispell-config.el) uses
  > call-process to run 'ispell -vv' and then searches the output
  > looking for a version number.
  >
  > Stepping thru this function, it appears to have failed because on
  > return from call-process, current-buffer is no longer ispell's
  > tmp buffer, but actually *scratch*.  Adding a set-buffer works
  > around the problem:
  >
  >     (save-excursion
  >       (set-buffer (get-buffer-create " *ispell-tmp*"))
  >       (erase-buffer)
  >       (setq status (call-process
  > 		    ispell-program-name nil t nil
  > 		    ;; aspell doesn't accept the -vv switch.
  > 		    (let ((case-fold-search
  > 			   (memq system-type '(ms-dos windows-nt)))
  > 			  (speller
  > 			   (file-name-nondirectory ispell-program-name)))
  > 		      ;; Assume anything that isn't `aspell' is Ispell.
  > 		      (if (string-match "\\`aspell" speller) "-v" "-vv"))))
  >  +++  (set-buffer " *ispell-tmp*")
  >       (goto-char (point-min))
  >       (if (not interactivep)
  > 	  ;; return library path.
  > 	  (if (re-search-forward "LIBDIR = \\\"\\([^ \t\n]*\\)\\\"" nil t)
  > 	      (setq result (buffer-substring (match-beginning 1)
  > 					     (match-end 1))))
  >
  > With 'xemacs -q', enable flyspell and then open a file, the
  > problem does NOT occur and flyspell and ispell seem to be doing
  > the right thing.  So clearly triggered by something in my setup.
  >
  > I haven't had time yet to see what in my setup is triggering this.
  > If no one else has seen or figured this out, I'll get to it again
  > in a day or 2.

  lazy-lock is either the culprit or the trigger here.

  If I have lazy-lock active, and font-lock enabled for dired mode,
  then call-process calls made on behalf of dired-mode may return
  with current-buffer as some other buffer.  Ditto for ispell-mode
  if the buffer has font-lock enabled.

  This problem did not start with 21.5.20, however.  It also
  happens with 21.5.18 and the latest packages as of 4/19/05.

  I'm pretty sure this actually started when I did a pkg update on
  4/19/05.  Most recent pkg update before that was on 1/19/05.

  -- 
  --tony






> 
> I'll try this as well but from my experience when the problem occurs you 
> are smoked. Trying the operation again does not reveal that much since 
> the situation is different. And the dired buffer is definitely not right 
> so you need to look out for other errors caused by that fact. Maybe 
> deleting the dired buffer and retrying the operation is worth a try if 
> the other way doesn't work out right.
> 
> Yours
> --
> %% Mats
>