From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: abbreviate-file-name on Windows seems incorrect Date: Sat, 06 Jan 2007 13:56:35 +0200 Message-ID: References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1168084616 25637 80.91.229.12 (6 Jan 2007 11:56:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 6 Jan 2007 11:56:56 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 06 12:56:56 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1H3AAM-0007Uf-J4 for ged-emacs-devel@m.gmane.org; Sat, 06 Jan 2007 12:56:50 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H3AAM-0002gK-4t for ged-emacs-devel@m.gmane.org; Sat, 06 Jan 2007 06:56:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H3AAA-0002fv-ST for emacs-devel@gnu.org; Sat, 06 Jan 2007 06:56:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H3AA9-0002fj-7C for emacs-devel@gnu.org; Sat, 06 Jan 2007 06:56:38 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H3AA9-0002fg-2K for emacs-devel@gnu.org; Sat, 06 Jan 2007 06:56:37 -0500 Original-Received: from [192.114.186.20] (helo=nitzan.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1H3AA8-0001Zk-Hf for emacs-devel@gnu.org; Sat, 06 Jan 2007 06:56:36 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-83-130-195-26.inter.net.il [83.130.195.26]) by nitzan.inter.net.il (MOS 3.7.3a-GA) with ESMTP id FQW88753 (AUTH halo1); Sat, 6 Jan 2007 13:56:34 +0200 (IST) Original-To: "Drew Adams" In-reply-to: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:64874 Archived-At: > From: "Drew Adams" > 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".