bug#7854: 24.0.50; Buffer *temp* modified; kill anyway?

bug#7854: 24.0.50; Buffer *temp* modified; kill anyway?

[Reiner Steib]

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

(a) emacs -Q -eval \
     "(defalias 'tramp-completion-file-name-handler 'file-name-non-special)"

     I added this alias because I couldn't prevent tramp kicking in
     (which adds quite a long delay the first time tramp is loaded) by
     simply customizing `tramp-mode' to nil, as I expected to from the
     doc string. Then I found that `file-name-handler-alist' has entries
     for `tramp-completion-file-name-handler' and
     `tramp-file-name-handler', and concluded that aliasing these to the
     default `file-name-non-special' might do the trick.

(b) M-x cvs-update RET

(c) I get a prompt like this:

     "Buffer  *temp* modified; kill anyway? "

(d) With M-x toggle-debug-on-quit RET, I get the following:

    Debugger entered--Lisp error: (quit)
      yes-or-no-p("Buffer  *temp*<4> modified; kill anyway? ")
      kill-buffer(#<buffer  *temp*<4>>)
      byte-code("[...]" [temp-buffer buffer-name kill-buffer] 2)
      byte-code([...] [temp-buffer cvs-cvsrc-file cmd --cl-dolist-temp-- sym
        val generate-new-buffer " *temp*" ((byte-code "..." [temp-buffer
        buffer-name kill-buffer] 2)) insert-file-contents ("cvs" "checkout"
        "status" "log" "diff" "tag" "add" "commit" "remove" "update") nil
        re-search-forward "^" "\\(\\s-+\\(.*\\)\\)?$" t intern "cvs-"
        "-flags" split-string-and-unquote match-string 2 "" 0 error
        "cvs-flags-defaults accessing a non-cvs-flags" 1 cvs-cvs-flags "-f"
        cvs-partition #[(x) "..." [x ("-q" "-Q" "-f")] 2] cvs-flags-query
        noquery value index cl-struct-cvs-flags-tags] 9)
      cvs-reread-cvsrc()
      execute-extended-command(nil)
      call-interactively(execute-extended-command nil nil)


In GNU Emacs 24.0.50.1 (i386-mingw-nt6.0.6002)
  of 2011-01-10 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 6.0.6002
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'

(I have the same behavior with 23.2)

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: DEU
   value of $XMODIFIERS: nil
   locale-coding-system: cp1252
   default enable-multibyte-characters: t

Major mode: Debugger

Minor modes in effect:
   tooltip-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
M-x c v s - u p <tab> <return> C-g M-x t o g g l e
- d e b u g - o n - q u i t <return> M-x <up> <up>
<return> C-g M-x r e p o r t - e m a c s - b u g <
return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
Debug on Quit enabled globally
Entering debugger...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader emacsbug
debug cus-start cus-load pcvs-parse pcvs-info pcvs-defs easymenu
easy-mmode pcvs-util ewoc tooltip ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev button minibuffer faces cus-face files text-properties overlay
md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

bug#7854: 24.0.50; Buffer *temp* modified; kill anyway?

[Stefan Monnier]

> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug.  If you can, give
> a recipe starting from `emacs -Q':

> (a) emacs -Q -eval \
>     "(defalias 'tramp-completion-file-name-handler 'file-name-non-special)"

>     I added this alias because I couldn't prevent tramp kicking in
>     (which adds quite a long delay the first time tramp is loaded) by
>     simply customizing `tramp-mode' to nil, as I expected to from the
>     doc string. Then I found that `file-name-handler-alist' has entries
>     for `tramp-completion-file-name-handler' and
>     `tramp-file-name-handler', and concluded that aliasing these to the
>     default `file-name-non-special' might do the trick.

> (b) M-x cvs-update RET

> (c) I get a prompt like this:

>     "Buffer  *temp* modified; kill anyway? "

Hmm... can't reproduce this here.  I get a prompt "CVS Update (directory):"
instead, and no matter what directory I select I don't get this bug.


        Stefan

bug#7854: 24.0.50; Buffer *temp* modified; kill anyway?

[Reiner Steib]

On Mon, Jan 17 2011, Stefan Monnier wrote:

>> (a) emacs -Q -eval \
>>     "(defalias 'tramp-completion-file-name-handler 'file-name-non-special)"
>
>>     I added this alias because I couldn't prevent tramp kicking in
>>     (which adds quite a long delay the first time tramp is loaded) by
>>     simply customizing `tramp-mode' to nil, as I expected to from the
>>     doc string. Then I found that `file-name-handler-alist' has entries
>>     for `tramp-completion-file-name-handler' and
>>     `tramp-file-name-handler', and concluded that aliasing these to the
>>     default `file-name-non-special' might do the trick.
>
>> (b) M-x cvs-update RET
>
>> (c) I get a prompt like this:
>
>>     "Buffer  *temp* modified; kill anyway? "
>
> Hmm... can't reproduce this here.  I get a prompt "CVS Update (directory):"
> instead, and no matter what directory I select I don't get this bug.

The bug happens before I can select the directory, so the specific
directory doesn't matter.

I neither can reproduce it on GNU/Linux, but on Windows, it is 100%
reproducible.  Any ideas how I can obtain more useful information from
the debug buffer?  Which *.el file should I load?

One more data point: The problem also happens e.g. when starting
Gnus.  My guess is that it happen when Emacs reads a file (.cvsrc,
...) into a temp buffer.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

bug#7854: 24.0.50; Buffer *temp* modified; kill anyway?

[Reiner Steib]

Reiner Steib writes:

> The bug happens before I can select the directory, so the specific
> directory doesn't matter.
> 
> I neither can reproduce it on GNU/Linux, but on Windows, it is 100%
> reproducible.  Any ideas how I can obtain more useful information from
> the debug buffer?  Which *.el file should I load?
> 
> One more data point: The problem also happens e.g. when starting
> Gnus.  My guess is that it happen when Emacs reads a file (.cvsrc,
> ...) into a temp buffer.

After moving ~/.cvsrc away, the bug doesn't happen. 
With a 0 byte ~/.cvsrc, the bug doesn't happen. 

With this simple .cvsrc, the bug triggers again:

$ cat --show-all ~/.cvsrc
#

(i.e. only one character '#', no CR, no newline).

When I answer "no" at the prompt "Buffer  *temp* modified; kill anyway?",
visit the buffer " *temp*", (point-max) is 2, and the mode line shows
iso-latin-1-dos as the coding system.

M-x describe-coding-system shows RET:

| Coding system for saving this buffer:
|   Not set locally, use the default.
| Default coding system (for new files):
|   1 -- iso-latin-1-dos (alias: iso-8859-1-dos latin-1-dos)

Bye, Reiner.

bug#7854: 24.0.50; Buffer *temp* modified; kill anyway?

[Stefan Monnier]

> After moving ~/.cvsrc away, the bug doesn't happen. 
> With a 0 byte ~/.cvsrc, the bug doesn't happen. 

> With this simple .cvsrc, the bug triggers again:

> $ cat --show-all ~/.cvsrc
> #

> (i.e. only one character '#', no CR, no newline).

So I guess the problem can be reproduced with

  emacs -Q --eval \
      "(defalias 'tramp-completion-file-name-handler 'file-name-non-special)"

and then M-x load-library RET pcvs RET.

I think I see the source of the problem.  In file-name-non-special we
do:

	(file-arg-indices
	 (cdr (or (assq operation
			;; The first six are special because they
			;; return a file name.  We want to include the /:
			;; in the return value.
			;; So just avoid stripping it in the first place.
			'((expand-file-name . nil)
                          [...]
			  ;; `quote' means add "/:" to buffer-file-name.
			  (insert-file-contents quote 0)
                          [...]
			  (add-name-to-file 0 1)))
          [...]
	  ((eq method 'quote)
	   (unwind-protect
	       (apply operation arguments)
	     (setq buffer-file-name (concat "/:" buffer-file-name))))

and indeed pcvs.el's cvs-read-cvsrc calls insert-file-contents, but not
in a way that should set buffer-file-name (i.e. it doesn't set the
`visit' argument).
I still don't understand why this shows up under w32 and not under
GNU/Linux, but I'm pretty sure that's the culprit.  Can you check to see
if the quick-fix below solves the problem?

             
        Stefan


=== modified file 'lisp/files.el'
--- lisp/files.el	2011-01-18 01:38:22 +0000
+++ lisp/files.el	2011-01-20 15:21:55 +0000
@@ -6165,7 +6165,8 @@
 	  ((eq method 'quote)
 	   (unwind-protect
 	       (apply operation arguments)
-	     (setq buffer-file-name (concat "/:" buffer-file-name))))
+             (if buffer-file-name
+                 (setq buffer-file-name (concat "/:" buffer-file-name)))))
 	  ((eq method 'unquote-then-quote)
 	   (let (res)
 	     (setq buffer-file-name (substring buffer-file-name 2))

bug#7854: 24.0.50; Buffer *temp* modified; kill anyway?

[Reiner Steib]

On Thu, Jan 20 2011, Stefan Monnier wrote:

> So I guess the problem can be reproduced with
>
>   emacs -Q --eval \
>       "(defalias 'tramp-completion-file-name-handler 'file-name-non-special)"
>
> and then M-x load-library RET pcvs RET.

Yes, that is another way I can reproduce it.

> I still don't understand why this shows up under w32 and not under
> GNU/Linux, but I'm pretty sure that's the culprit.  

Maybe a line-endings issue?

> Can you check to see if the quick-fix below solves the problem?

It solves the problem.  Thank you!

> -	     (setq buffer-file-name (concat "/:" buffer-file-name))))
> +             (if buffer-file-name
> +                 (setq buffer-file-name (concat "/:" buffer-file-name)))))

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

bug#7854: 24.0.50; Buffer *temp* modified; kill anyway?

[Stefan Monnier]

>> Can you check to see if the quick-fix below solves the problem?
> It solves the problem.  Thank you!

Thanks for confirming.  I've installed the patch below in the emacs-23
branch, which should fix it right.


        Stefan


=== modified file 'lisp/files.el'
--- lisp/files.el	2011-01-20 02:55:36 +0000
+++ lisp/files.el	2011-01-24 20:22:34 +0000
@@ -6118,8 +6118,7 @@
 			  (substitute-in-file-name identity)
 			  ;; `add' means add "/:" to the result.
 			  (file-truename add 0)
-			  ;; `quote' means add "/:" to buffer-file-name.
-			  (insert-file-contents quote 0)
+			  (insert-file-contents insert-file-contents 0)
 			  ;; `unquote-then-quote' means set buffer-file-name
 			  ;; temporarily to unquoted filename.
 			  (verify-visited-file-modtime unquote-then-quote)
@@ -6150,20 +6149,18 @@
 			   "/"
 			 (substring (car pair) 2)))))
 	(setq file-arg-indices (cdr file-arg-indices))))
-    (cond ((eq method 'identity)
-	   (car arguments))
-	  ((eq method 'add)
-	   (concat "/:" (apply operation arguments)))
-	  ((eq method 'quote)
-	   (unwind-protect
+    (case method
+      (identity (car arguments))
+      (add (concat "/:" (apply operation arguments)))
+      (insert-file-contents
+       (let ((visit (nth 1 arguments)))
+         (prog1
 	       (apply operation arguments)
-	     (setq buffer-file-name (concat "/:" buffer-file-name))))
-	  ((eq method 'unquote-then-quote)
-	   (let (res)
-	     (setq buffer-file-name (substring buffer-file-name 2))
-	     (setq res (apply operation arguments))
-	     (setq buffer-file-name (concat "/:" buffer-file-name))
-	     res))
+           (when (and visit buffer-file-name)
+             (setq buffer-file-name (concat "/:" buffer-file-name))))))
+      (unquote-then-quote
+       (let ((buffer-file-name (substring buffer-file-name 2)))
+         (apply operation arguments)))
 	  (t
 	   (apply operation arguments)))))
 \f

bug#7854: emacs-23 (regression) - fix breaks `dired' (was: bug#7854: 24.0.50; Buffer *temp* modified; kill anyway?)

[Reiner Steib]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> 
> >> Can you check to see if the quick-fix below solves the problem?
> > It solves the problem.  Thank you!
> 
> Thanks for confirming.  I've installed the patch below in the emacs-23
> branch, which should fix it right.

This is the relevant commit:

+2011-01-24 Stefan Monnier <monnier@iro.umontreal.ca>
+
+ * files.el (file-name-non-special): Only change buffer-file-name after
+ insert-file-contents if it's `visit'ing the file (bug#7854).

It fixed the original problem, but there's a regression: It breaks `dired' for
me (not sure if I should have opened a new bug?):

$ emacs -Q -l files-emacs23-git.el --eval '(dired "u:/tmp/")'
(files-emacs23-git.el =
http://git.savannah.gnu.org/cgit/emacs.git/plain/lisp/files.el?h=emacs-23&id=8588a5a723f4e5cfa115341a242126a9efc71808)

I get:

| if: Reading directory: "ls -al -- u:/tmp/" exited with status 1

$ emacs -Q -l files-emacs23-git.el -f toggle-debug-on-error \
    --eval '(dired "u:/tmp/")'

| dired-readin()
| dired-internal-noselect("u:/tmp/" nil)
| dired-noselect("u:/tmp/" nil)
| dired("u:/tmp/")
| eval((dired "u:/tmp/"))
| command-line-1(("-l" "files-emacs23-git.el" "-f"
|   "toggle-debug-on-error" "--eval" "(dired \"u:/tmp/\")"))
| command-line()
| normal-top-level()

Edebuging `dired-internal-noselect' ...

| edebug-enter(dired-internal-noselect ("u:/tmp/" nil nil) (lambda nil
|   (edebug-after (edebug-before 0) 121 (let*
|   ... ... ... ... ... ...))))
| dired-internal-noselect("u:/tmp/" nil)
| dired-noselect("u:/tmp/" nil)
| dired("u:/tmp/" nil)
| call-interactively(dired t nil)
| execute-extended-command(nil)
| call-interactively(execute-extended-command nil nil)
| recursive-edit()
| byte-code("..." [unread-command-char debugger-args x debugger-buffer
|   noninteractive debugger-batch-max-lines -1 debug backtrace-debug 4 t
|   backtrace-frame lambda 5 pop-to-buffer debugger-mode
|   debugger-setup-buffer count-lines 2 "...\n" message "%s"
|   buffer-string kill-emacs "" nil recursive-edit middlestart
|   buffer-read-only standard-output] 4)
| debug(error (error "Reading directory: \"ls -al -- u:/tmp/\" exited
|   with status 1"))
| signal(error ("Reading directory: \"ls -al -- u:/tmp/\" exited with
|   status 1"))
| error("Reading directory: \"%s %s -- %s\" exited with status %s"
|   "ls" "-al" "u:/tmp/" 1)
| (if (and (file-directory-p file) (memq system-type ...)) (error
|   "Reading directory: \"%s %s -- %s\" exited with status %s"
|   insert-directory-program (if ... ... switches) file result)
|   (access-file file "Reading directory") (error "Listing directory
|   failed but `access-file' worked"))
| (if (eq 0 result) nil (delete-region beg (point)) (if (and ... ...)
|   (error "Reading directory: \"%s %s -- %s\" exited with status %s"
|   insert-directory-program ... file result) (access-file file "Reading
|   directory") (error "Listing directory failed but `access-file'
|   worked")))
| (unless (eq 0 result) (delete-region beg (point)) (if (and ... ...)
|   (error "Reading directory: \"%s %s -- %s\" exited with status %s"
|   insert-directory-program ... file result) (access-file file "Reading
|   directory") (error "Listing directory failed but `access-file'
|   worked")))
| (let (result (beg ...)) (let* (... ...) (setq result ...)) (when (if
|   ... ... ...) (save-excursion ... ... ...)) (when (and ... ...) (let
|   ... ...)) (when (and ... ...) (setq result 0)) (unless (eq 0 result)
|   (delete-region beg ...) (if ... ... ... ...)) (when (if ... ... ...)
|   (forward-line -2) (when ... ... ...) (if ... ... ...) (if ... ...))
|   (let (... coding-no-eol val pos) (when ... ... ...)) (if
|   full-directory-p (save-excursion ... ...)))
| (if handler (funcall handler (quote insert-directory) file switches
|   wildcard full-directory-p) (let (result ...) (let* ... ...) (when
|   ... ...) (when ... ...) (when ... ...) (unless ... ... ...) (when
|   ... ... ... ... ...) (let ... ...) (if full-directory-p ...)))
| (let ((handler ...)) (if handler (funcall handler ... file switches
|   wildcard full-directory-p) (let
|   ... ... ... ... ... ... ... ... ...)))
| insert-directory("u:/tmp/" "-al" nil t)
| dired-insert-directory("u:/tmp/" "-al" nil nil t)
| dired-readin-insert()
| dired-readin()
| dired-internal-noselect("u:/tmp/" nil)
| dired-noselect("u:/tmp/" nil)
| dired("u:/tmp/")
| eval((dired "u:/tmp/"))
| command-line-1(("-l" "files-emacs23-git.el" "-f"
|   "toggle-debug-on-error" "--eval" "(dired \"u:/tmp/\")"))
| command-line()
| normal-top-level()

| $ u:/bin/ls --version
| ls (fileutils) 4.4.219 2010/05
| Written by Richard Stallman and David MacKenzie
| Microsoft Windows extensions by Alan Klietz.
| 
| Copyright (C) 2001 Free Software Foundation, Inc.
| 
| Microsoft Windows extensions copyright (C) 2010, Algin Technology LLC
| Distributed under GNU General Public License version 2.
| 
| This is free software; see the source for copying conditions.  There is NO
| warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Executing (shell-command-to-string "ls -al u:/tmp/") in IELM gives
resonable a result.

bug#7854: emacs-23 (regression) - fix breaks `dired'

[Chong Yidong]

Could someone with access to Windows please test the regression reported
at Bug#7854?  I could not reproduce it, replacing "u:/tmp" with "/tmp/".

> $ emacs -Q -l files-emacs23-git.el --eval '(dired "u:/tmp/")'
> (files-emacs23-git.el =
> http://git.savannah.gnu.org/cgit/emacs.git/plain/lisp/files.el?h=emacs-23&id=8588a5a723f4e5cfa115341a242126a9efc71808)
>
> I get:
>
> | if: Reading directory: "ls -al -- u:/tmp/" exited with status 1

If someone could come up with a smaller testcase, that would be good
too.

Re: bug#7854: emacs-23 (regression) - fix breaks `dired'

[Chong Yidong]

Could someone with access to Windows please test the regression reported
at Bug#7854?  I could not reproduce it, replacing "u:/tmp" with "/tmp/".

> $ emacs -Q -l files-emacs23-git.el --eval '(dired "u:/tmp/")'
> (files-emacs23-git.el =
> http://git.savannah.gnu.org/cgit/emacs.git/plain/lisp/files.el?h=emacs-23&id=8588a5a723f4e5cfa115341a242126a9efc71808)
>
> I get:
>
> | if: Reading directory: "ls -al -- u:/tmp/" exited with status 1

If someone could come up with a smaller testcase, that would be good
too.

bug#7854: emacs-23 (regression) - fix breaks `dired'

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat, 12 Feb 2011 15:20:06 -0500
> Cc: 7854@debbugs.gnu.org, Reiner Steib <reinersteib+gmane@imap.cc>
> 
> Could someone with access to Windows please test the regression reported
> at Bug#7854?  I could not reproduce it, replacing "u:/tmp" with "/tmp/".
> 
> > $ emacs -Q -l files-emacs23-git.el --eval '(dired "u:/tmp/")'
> > (files-emacs23-git.el =
> > http://git.savannah.gnu.org/cgit/emacs.git/plain/lisp/files.el?h=emacs-23&id=8588a5a723f4e5cfa115341a242126a9efc71808)
> >
> > I get:
> >
> > | if: Reading directory: "ls -al -- u:/tmp/" exited with status 1
> 
> If someone could come up with a smaller testcase, that would be good
> too.

I cannot reproduce this with the current trunk (replacing u:/tmp with
a directory I actually have on my system).  Up comes Dired with the
listing of that directory.  The only way I can cause it to fail is by
removing ls.exe from my PATH -- but that produces a different error
message:

  Debugger entered--Lisp error: (file-error "Searching for program" "no such file or directory" "ls")
    call-process("ls" nil t nil "-al" "--" "h:/test/.")
    apply(call-process "ls" nil t nil ("-al" "--" "h:/test/."))

This error is expected: loading files.el overrides the replacement
functions installed by ls-lisp.el (which is preloaded on Windows), so
now Dired on Windows must have a working ls.exe executable.  (I
actually don't understand what is the purpose of loading files.el from
Emacs 23 into Emacs 24, but that's me.)

Reiner, can you still see this problem in today's trunk?

Re: bug#7854: emacs-23 (regression) - fix breaks `dired'

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat, 12 Feb 2011 15:20:06 -0500
> Cc: 7854@debbugs.gnu.org, Reiner Steib <reinersteib+gmane@imap.cc>
> 
> Could someone with access to Windows please test the regression reported
> at Bug#7854?  I could not reproduce it, replacing "u:/tmp" with "/tmp/".
> 
> > $ emacs -Q -l files-emacs23-git.el --eval '(dired "u:/tmp/")'
> > (files-emacs23-git.el =
> > http://git.savannah.gnu.org/cgit/emacs.git/plain/lisp/files.el?h=emacs-23&id=8588a5a723f4e5cfa115341a242126a9efc71808)
> >
> > I get:
> >
> > | if: Reading directory: "ls -al -- u:/tmp/" exited with status 1
> 
> If someone could come up with a smaller testcase, that would be good
> too.

I cannot reproduce this with the current trunk (replacing u:/tmp with
a directory I actually have on my system).  Up comes Dired with the
listing of that directory.  The only way I can cause it to fail is by
removing ls.exe from my PATH -- but that produces a different error
message:

  Debugger entered--Lisp error: (file-error "Searching for program" "no such file or directory" "ls")
    call-process("ls" nil t nil "-al" "--" "h:/test/.")
    apply(call-process "ls" nil t nil ("-al" "--" "h:/test/."))

This error is expected: loading files.el overrides the replacement
functions installed by ls-lisp.el (which is preloaded on Windows), so
now Dired on Windows must have a working ls.exe executable.  (I
actually don't understand what is the purpose of loading files.el from
Emacs 23 into Emacs 24, but that's me.)

Reiner, can you still see this problem in today's trunk?

bug#7854: emacs-23 (regression) - fix breaks `dired'

[Reiner Steib]

On Sat, 12 Feb 2011 23:11 +0200, "Eli Zaretskii" <eliz@gnu.org> wrote:
> > From: Chong Yidong <cyd@stupidchicken.com>
> > Date: Sat, 12 Feb 2011 15:20:06 -0500
> > Cc: 7854@debbugs.gnu.org, Reiner Steib <reinersteib+gmane@imap.cc>
> > 
> > Could someone with access to Windows please test the regression reported
> > at Bug#7854?  I could not reproduce it, replacing "u:/tmp" with "/tmp/".
> > 
> > > $ emacs -Q -l files-emacs23-git.el --eval '(dired "u:/tmp/")'
> > > (files-emacs23-git.el =
> > > http://git.savannah.gnu.org/cgit/emacs.git/plain/lisp/files.el?h=emacs-23&id=8588a5a723f4e5cfa115341a242126a9efc71808)
> > >
> > > I get:
> > >
> > > | if: Reading directory: "ls -al -- u:/tmp/" exited with status 1
> > 
> > If someone could come up with a smaller testcase, that would be good
> > too.
> 
> I cannot reproduce this with the current trunk (replacing u:/tmp with
> a directory I actually have on my system).  Up comes Dired with the
> listing of that directory.  The only way I can cause it to fail is by
> removing ls.exe from my PATH -- but that produces a different error
> message:
> 
>   Debugger entered--Lisp error: (file-error "Searching for program" "no
>   such file or directory" "ls")
>     call-process("ls" nil t nil "-al" "--" "h:/test/.")
>     apply(call-process "ls" nil t nil ("-al" "--" "h:/test/."))
> 
> This error is expected: loading files.el overrides the replacement
> functions installed by ls-lisp.el (which is preloaded on Windows), so
> now Dired on Windows must have a working ls.exe executable.  

Thanks for the explanation.

> (I actually don't understand what is the purpose of loading files.el
> from Emacs 23 into Emacs 24, but that's me.)

As I use a pre-compiled Emacs (when using Windows), I loaded the most
recent version of files.el for the emacs-23 branch from git-web (with
Stefans's fix for the original problem) on the command line (using emacs
23.2) because the old files.elc is dumped (if I understand correctly).
The original problem was reported for the trunk, but the (potential)
regression was found in the emacs-23 branch.  Sorry for the confusion.
 
> Reiner, can you still see this problem in today's trunk?

Now I downloaded the most recent binaries: 23.3 pretest
(emacs-23.2.93-bin-i386.zip) and trunk (emacs-20110207-bin-i386.zip).

I cannot reproduce the problem with these versions.  So please close
this bug again - sorry for the noise.

Bye, Reiner

-- 
http://www.fastmail.fm - mmm... Fastmail...

Re: bug#7854: emacs-23 (regression) - fix breaks `dired'

[Reiner Steib]

On Sat, 12 Feb 2011 23:11 +0200, "Eli Zaretskii" <eliz@gnu.org> wrote:
> > From: Chong Yidong <cyd@stupidchicken.com>
> > Date: Sat, 12 Feb 2011 15:20:06 -0500
> > Cc: 7854@debbugs.gnu.org, Reiner Steib <reinersteib+gmane@imap.cc>
> > 
> > Could someone with access to Windows please test the regression reported
> > at Bug#7854?  I could not reproduce it, replacing "u:/tmp" with "/tmp/".
> > 
> > > $ emacs -Q -l files-emacs23-git.el --eval '(dired "u:/tmp/")'
> > > (files-emacs23-git.el =
> > > http://git.savannah.gnu.org/cgit/emacs.git/plain/lisp/files.el?h=emacs-23&id=8588a5a723f4e5cfa115341a242126a9efc71808)
> > >
> > > I get:
> > >
> > > | if: Reading directory: "ls -al -- u:/tmp/" exited with status 1
> > 
> > If someone could come up with a smaller testcase, that would be good
> > too.
> 
> I cannot reproduce this with the current trunk (replacing u:/tmp with
> a directory I actually have on my system).  Up comes Dired with the
> listing of that directory.  The only way I can cause it to fail is by
> removing ls.exe from my PATH -- but that produces a different error
> message:
> 
>   Debugger entered--Lisp error: (file-error "Searching for program" "no
>   such file or directory" "ls")
>     call-process("ls" nil t nil "-al" "--" "h:/test/.")
>     apply(call-process "ls" nil t nil ("-al" "--" "h:/test/."))
> 
> This error is expected: loading files.el overrides the replacement
> functions installed by ls-lisp.el (which is preloaded on Windows), so
> now Dired on Windows must have a working ls.exe executable.  

Thanks for the explanation.

> (I actually don't understand what is the purpose of loading files.el
> from Emacs 23 into Emacs 24, but that's me.)

As I use a pre-compiled Emacs (when using Windows), I loaded the most
recent version of files.el for the emacs-23 branch from git-web (with
Stefans's fix for the original problem) on the command line (using emacs
23.2) because the old files.elc is dumped (if I understand correctly).
The original problem was reported for the trunk, but the (potential)
regression was found in the emacs-23 branch.  Sorry for the confusion.
 
> Reiner, can you still see this problem in today's trunk?

Now I downloaded the most recent binaries: 23.3 pretest
(emacs-23.2.93-bin-i386.zip) and trunk (emacs-20110207-bin-i386.zip).

I cannot reproduce the problem with these versions.  So please close
this bug again - sorry for the noise.

Bye, Reiner

-- 
http://www.fastmail.fm - mmm... Fastmail...