Re: find-directory-p always returns nil in locate-mode on windows xp

[Luc Teirlinck]

Eli Zaretskii wrote:

   There are several issues that I'd like us to try to solve:

     - why did you get on GNU/Linux a concatenation of your home
       directory and the file name, as in
       "/home/teirllm/home/teirllm/compdir/"? where's the code that did
       that, and why that doesn't happen on MS-DOS?

I still am a little bit confused here.  We both seem to agree that `i'
works (well, kind of) if default-directory is "/" and does not if
default-directory is something else.  We are trying to find out
whether "/" yields problems on MS Windows.  So why do you want me to
find out what happens if default-directory is "~/" on GNU/Linux?  I
will still do that if for some reason it actually is relevant, but
below is the answer when the default directory is "/", which I believe
is the relevant case.

The concatenation of the default-directory "/" with the file name
relative to "/" (absolute file name minus leading `/') happens, for
`i' and RET (but interestingly enough not for V, so it might actually
not be _that_ relevant) in `dired-get-filename' on lines 1653 and 1654
in dired.el:

     ((equal (dired-current-directory) "/")
      (setq file (concat (dired-current-directory localp) file))

@var{localp} is nil.
The return value of (dired-current-directory) is "/" at the time the
code is executed.  (Obviously, otherwise it would not get executed.)
That return value is obtained from dired-subdir-alist.

If RET was pressed on:

    /home/teirllm/compdir

The value of @var{file} is: home/teirllm/compdir.

Because of the value of `dired-move-to-filename-regexp' in the *Locate*
buffer, dired-get-filename refused to read the leading "/" earlier.

Sincerely,

Luc.