Re: abbreviate-file-name on Windows seems incorrect

[Eli Zaretskii]

> From: "Drew Adams" <address@hidden>
> Date: Fri, 5 Jan 2007 23:56:45 -0800
> 
> (or abbreviated-home-dir
>     (setq abbreviated-home-dir
>           (let ((abbreviated-home-dir "$foo"))
>             (concat "^" (abbreviate-file-name
>                          (expand-file-name "~"))
>                     "\\(/\\|\\'\\)"))))
> 
> The comment for this code is as follows, which indicates that a slash is
> added to distinguish the home dir from a file in that dir:
> 
>     ;; We include a slash at the end, to avoid spurious matches
>     ;; such as `/usr/foobar' when the home dir is `/usr/foo'.
> 
> However, that is improper for a Windows home directory such as mine (not an
> uncommon value).  (expand-file-name "~") returns "c:/", which is correct,
> but the result for `abbreviated-home-dir' becomes "^c:/\\(/\\|\\'\\)", which
> is incorrect and useless, AFAICT. It should be something like
> "^c:\\(/\\|\\'\\)", I would think.

Please explain why you think the value of `abbreviated-home-dir' is
useless, given what I tell below.  I don't think it's useless, at
least not in when the home directory is something other than a root on
some drive.

> I would expect (abbreviate-file-name "c:/foo/bar") to return "~/foo/bar",
> but it returns "c:/foo/bar".

This is a feature: the Windows port behaves here like the Unix version
does, and doesn't change the file name if the home directory is a root
directory.  Here's the relevant portion of abbreviate-file-name:

      ;; If FILENAME starts with the abbreviated homedir,
      ;; make it start with `~' instead.
      (if (and (string-match abbreviated-home-dir filename)
               ;; If the home dir is just /, don't change it.
               (not (and (= (match-end 0) 1)
                         (= (aref filename 0) ?/)))
               ;; MS-DOS root directories can come with a drive letter;
               ;; Novell Netware allows drive letters beyond `Z:'.
               (not (and (or (eq system-type 'ms-dos)
                             (eq system-type 'cygwin)
                             (eq system-type 'windows-nt))
                         (save-match-data
                           (string-match "^[a-zA-`]:/$" filename)))))
          (setq filename
                (concat "~"
                        (match-string 1 filename)
                        (substring filename (match-end 0)))))

This explicitly makes a point of being consistent with Unix, and I
don't see anything wrong with that; do you?

> The point is that I don't see how the current regexp could ever work for a
> Windows $HOME that starts with a drive letter. This seems like a bug, to me.
> This behavior is the same in Emacs 20, 21, and 22, but I think it is wrong.

Please explain why you think it's a bug.  Again, in the case where
$HOME is a root directory, this is a deliberate feature, but your
statement above seems to be more general: it seems to say that the
current regexp is _never_ correct for a value of $HOME such as
d:/foo/bar/baz, and that is certainly not so.  E.g., my $HOME's value
is "d:/usr/eli", and abbreviate-file-name works for me:

  (abbreviate-file-name "d:/usr/eli/foo/bar") => "~/foo/bar"

> Since `abbreviate-file-name' is used a lot, I imagine that the code that
> uses it must be compensating for this bug somehow when it comes to Windows,

What bug?  Please take a look at abbreviate-file-name, it's in
files.el.  The only Windows-specific code there is the one that
mimics the Posix behavior with $HOME being a root directory.

> I want to be able to do, for instance, (abbreviate-file-name
> (expand-file-name "~/WHATEVER")), and have it work normally on Windows,
> returning "~/WHATEVER". It currently does not - it returns "c:/WHATEVER"
> instead.

What do you want it to do on Unix if $HOME is "/"?  It currently
returns "/WHATEVER", not "~/WHATEVER".