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

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...

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: 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.