From: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: abbreviate-file-name on Windows seems incorrect
Date: Sat, 06 Jan 2007 13:56:35 +0200 [thread overview]
Message-ID: <ulkkgz7v0.fsf@gnu.org> (raw)
In-Reply-To: <BDEIJAFNGDOAGCJIPKPBGEMJCBAA.drew.adams@oracle.com>
> From: "Drew Adams" <drew.adams@oracle.com>
> 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".
next prev parent reply other threads:[~2007-01-06 11:56 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-06 7:56 abbreviate-file-name on Windows seems incorrect Drew Adams
2007-01-06 11:37 ` Lennart Borgman (gmail)
2007-01-06 14:18 ` Eli Zaretskii
2007-01-06 15:03 ` Lennart Borgman (gmail)
2007-01-06 11:56 ` Eli Zaretskii [this message]
2007-01-06 16:22 ` Drew Adams
2007-01-06 21:51 ` Eli Zaretskii
2007-01-06 22:42 ` Drew Adams
2007-01-07 2:44 ` Miles Bader
2007-01-07 4:12 ` Eli Zaretskii
2007-01-07 14:29 ` Stephen Leake
2007-01-07 20:47 ` Eli Zaretskii
2007-01-07 22:03 ` Drew Adams
2007-01-07 22:08 ` Drew Adams
2007-01-08 1:40 ` Chris Moore
2007-01-08 2:04 ` Drew Adams
2007-01-08 10:15 ` Jason Rumney
2007-01-08 16:29 ` Drew Adams
2007-01-09 0:01 ` Richard Stallman
2007-01-09 0:30 ` Jason Rumney
2007-01-09 12:55 ` Stephen Leake
2007-01-09 17:57 ` Richard Stallman
2007-01-08 8:44 ` Stephen Leake
2007-01-08 13:07 ` Chris Moore
2007-01-08 19:30 ` Eli Zaretskii
2007-01-09 12:52 ` Stephen Leake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ulkkgz7v0.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.