abbreviate-file-name on Windows seems incorrect

abbreviate-file-name on Windows seems incorrect

[Drew Adams]

On MS Windows, my $HOME is "c:\\". That is what is returned by (getenv
"HOME"), and that is what I see in Windows itself, in the list of
environment vars.

The code for `abbreviate-file-name' defines `abbreviated-home-dir' as
follows, in order to be able to "substitute `~' for the user's home
directory", as the doc string says:

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

I would expect (abbreviate-file-name "c:/foo/bar") to return "~/foo/bar",
but it returns "c:/foo/bar". If `abbreviated-home-dir' were
"^c:\\(/\\|\\'\\)", then the result would be correct: "~/foo/bar".

I'm not sure exactly what the resulting regexp should be or how it should be
constructed.  "^c:\\(/\\|\\'\\)" works for "c:/foo/bar" (returning
"~/foo/bar"), but not for "c:/" (it returns "c:/", not "~").

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.

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,
or else there are other, dependent bugs lurking elsewhere. (?)

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. It should also work for empty WHATEVER, of course (i.e. "~/" and
"~").

Re: abbreviate-file-name on Windows seems incorrect

[Lennart Borgman (gmail)]

Drew Adams wrote:
> On MS Windows, my $HOME is "c:\\". That is what is returned by (getenv
> "HOME"), and that is what I see in Windows itself, in the list of
> environment vars.
> 
> The code for `abbreviate-file-name' defines `abbreviated-home-dir' as
> follows, in order to be able to "substitute `~' for the user's home
> directory", as the doc string says:
> 
> (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.
> 
> I would expect (abbreviate-file-name "c:/foo/bar") to return "~/foo/bar",
> but it returns "c:/foo/bar". If `abbreviated-home-dir' were
> "^c:\\(/\\|\\'\\)", then the result would be correct: "~/foo/bar".



If leave abbreviated-home-dir as "^c:/\\(/\\|\\'\\)" and you instead 
just comment out this part in abbreviate-file-name, does it works as you 
expect then? :

	       ;; 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)))))

Re: abbreviate-file-name on Windows seems incorrect

[Eli Zaretskii]

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

Re: abbreviate-file-name on Windows seems incorrect

[Eli Zaretskii]

> Date: Sat, 06 Jan 2007 12:37:25 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: Emacs-Devel <emacs-devel@gnu.org>
> 
> If leave abbreviated-home-dir as "^c:/\\(/\\|\\'\\)" and you instead 
> just comment out this part in abbreviate-file-name, does it works as you 
> expect then? :
> 
> 	       ;; 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)))))

Why remove it?  It does on Windows what the preceding fragment (the
one you didn't show) does on Unix.

Re: abbreviate-file-name on Windows seems incorrect

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Sat, 06 Jan 2007 12:37:25 +0100
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> Cc: Emacs-Devel <emacs-devel@gnu.org>
>>
>> If leave abbreviated-home-dir as "^c:/\\(/\\|\\'\\)" and you instead 
>> just comment out this part in abbreviate-file-name, does it works as you 
>> expect then? :
>>
>> 	       ;; 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)))))
> 
> Why remove it?  It does on Windows what the preceding fragment (the
> one you didn't show) does on Unix.


Yes, I know. I did not argue for removing it, but I could have said that 
of course.

RE: abbreviate-file-name on Windows seems incorrect

[Drew Adams]

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

OK.

> my $HOME's value is "d:/usr/eli":
> (abbreviate-file-name "d:/usr/eli/foo/bar") => "~/foo/bar"

I see. To tell the truth, I didn't bother to change $HOME outside Emacs and
start emacs -Q again to test the case other than HOME = "c:\\". I did try
using `setenv' to change "HOME", but that apparently doesn't have an effect
here. That is:

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

So, I didn't notice that it does work properly. Setting $HOME in Windows
itself to "d:\eli\" and then starting emacs -Q, I do get what you showed:

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

So, I was mistaken - no problem. Thx for the clear explanation.

How about mentioning in the doc string that "~" is not substituted for the
user's home dir if that is the root. ("/" in Unix or Linux,
"<drive-letter>:\" in Windows)? The doc string gives an incorrect idea of
what the function does, in this case (which is common in Windows).

Re: abbreviate-file-name on Windows seems incorrect

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 6 Jan 2007 08:22:09 -0800
> 
> I see. To tell the truth, I didn't bother to change $HOME outside Emacs and
> start emacs -Q again to test the case other than HOME = "c:\\". I did try
> using `setenv' to change "HOME", but that apparently doesn't have an effect
> here.

setenv only manipulates the environment that is passed to child
processes, but does not modify Emacs's own environment.

> How about mentioning in the doc string that "~" is not substituted for the
> user's home dir if that is the root. ("/" in Unix or Linux,
> "<drive-letter>:\" in Windows)?

Done.

RE: abbreviate-file-name on Windows seems incorrect

[Drew Adams]

> > I see. To tell the truth, I didn't bother to change $HOME
> > outside Emacs and start emacs -Q again to test the case other
> > than HOME = "c:\\". I did try using `setenv' to change "HOME",
> > but that apparently doesn't have an effect here.
>
> setenv only manipulates the environment that is passed to child
> processes, but does not modify Emacs's own environment.

Right. That's what I concluded, after your first explanation.

The `setenv' doc string does speak of `process-environment', but I think it
wouldn't hurt to explicitly point out that the current environment that
Emacs itself sees is not affected.

> > How about mentioning in the doc string that "~" is not
> > substituted for the user's home dir if that is the root.
> > ("/" in Unix or Linux, "<drive-letter>:\" in Windows)?
>
> Done.

Thx.

Re: abbreviate-file-name on Windows seems incorrect

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> setenv only manipulates the environment that is passed to child
> processes, but does not modify Emacs's own environment.

???

In my Emacs, under debian, M-x setenv certainly seems to affect the
"Emacs environment" that the user sees.

In particular, doing (setenv "foo" ...) allows $foo to be used when
visiting files (i.e. substitute-in-file-name sees it), and doing
(setenv "HOME" ...) changes how expand-file-name expands a tilde.

If this doesn't happen in windows, it seems like a bug...

-Miles

-- 
((lambda (x) (list x x)) (lambda (x) (list x x)))

Re: abbreviate-file-name on Windows seems incorrect

[Eli Zaretskii]

> Cc: "Drew Adams" <drew.adams@oracle.com>,  emacs-devel@gnu.org
> From: Miles Bader <miles@gnu.org>
> Date: Sun, 07 Jan 2007 11:44:10 +0900
> 
> In particular, doing (setenv "foo" ...) allows $foo to be used when
> visiting files (i.e. substitute-in-file-name sees it), and doing
> (setenv "HOME" ...) changes how expand-file-name expands a tilde.
> 
> If this doesn't happen in windows, it seems like a bug...

I tried, and it does happen on Windows, of course.

Re: abbreviate-file-name on Windows seems incorrect

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: "Drew Adams" <drew.adams@oracle.com>,  emacs-devel@gnu.org
>> From: Miles Bader <miles@gnu.org>
>> Date: Sun, 07 Jan 2007 11:44:10 +0900
>> 
>> In particular, doing (setenv "foo" ...) allows $foo to be used when
>> visiting files (i.e. substitute-in-file-name sees it), 

This works on Windows (at least for me).

This is very convenient; the files Emacs finds via environment
variables is the same as the files that subprocesses find via the same
environment variables, even when those environment variables are set
from within Emacs. So I can change what I'm working on without leaving
Emacs.

>> and doing (setenv "HOME" ...) changes how expand-file-name expands
>> a tilde.

This does not happen on Windows (for me). I don't have a non-Windows
emacs handy to try.

It seems appropriate for Emacs to "latch" the value of $HOME at
startup, so the location of .emacs doesn't change, for example. There
are other files that are located in $HOME as well; you don't want them
moving around either.

But it is inconsistent with the handling of other environment variables.

>> If this doesn't happen in windows, it seems like a bug...
>
> I tried, and it does happen on Windows, of course.

Which of the two tests did you try?

-- 
-- Stephe

Re: abbreviate-file-name on Windows seems incorrect

[Eli Zaretskii]

> Cc: Miles Bader <miles@gnu.org>, drew.adams@oracle.com, emacs-devel@gnu.org
> From: Stephen Leake <stephen_leake@member.fsf.org>
> Date: Sun, 07 Jan 2007 09:29:37 -0500
> 
> >> and doing (setenv "HOME" ...) changes how expand-file-name expands
> >> a tilde.
> 
> This does not happen on Windows (for me). I don't have a non-Windows
> emacs handy to try.
> [...]
> > I tried, and it does happen on Windows, of course.
> 
> Which of the two tests did you try?

Both, and they both worked.

Please show your precise test case (in "emacs -Q").

Also, please tell what is your initial value of HOME (outside Emacs).

RE: abbreviate-file-name on Windows seems incorrect

[Drew Adams]

It seems that `abbreviate-file-name' does not recognize the effect of using
`setenv' inside Emacs (on Windows).

1. Outside Emacs, set $HOME to c:\ ("c:\\" as a Lisp string).

emacs -Q

(getenv "HOME") ; => "c:\\"
(setenv "HOME" "c:/drews-lisp-20/")
  ; => "c:/drews-lisp-20/"
(abbreviate-file-name "c:/drews-lisp-20/")
  ; => "c:/drews-lisp-20/" (EXPECTED "~/")

That is, I would expect $HOME to be replaced by ~/ (or perhaps ~), but it
was not.


2. Outside Emacs, set $HOME to c:\drews-lisp-20\.

emacs -Q

(getenv "HOME") ; => "c:\\drews-lisp-20\\"
(abbreviate-file-name "c:/drews-lisp-20/")
 ; => "~/"

(setenv "HOME" "c:/drews-lisp-20/")
  ; => "c:/drews-lisp-20/"
(abbreviate-file-name "c:/drews-lisp-20/")
  ; => "~/"

`directory-abbrev-alist' remained nil throughout both tests.

RE: abbreviate-file-name on Windows seems incorrect

[Drew Adams]

Followup info:

1. It's about `abbreviate-file-name', not `expand-file-name' or
`substitute-in-file-name'. See subject line and original report I sent.

2. In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600)
 of 2006-12-11 on LENNART-69DE564
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Id:/g/include'

Re: abbreviate-file-name on Windows seems incorrect

[Chris Moore]

"Drew Adams" <drew.adams@oracle.com> writes:

> Followup info:
>
> 1. It's about `abbreviate-file-name', not `expand-file-name' or
> `substitute-in-file-name'. See subject line and original report I sent.

The value of HOME is cached the first time abbreviate-file-name is
called, and never updated, using exactly the code you quoted here:

> The code for `abbreviate-file-name' defines `abbreviated-home-dir' as
> follows, in order to be able to "substitute `~' for the user's home
> directory", as the doc string says:
>
> (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:

If you look up 3 lines from that comment about the slash, you'll see:

      ;; Compute and save the abbreviated homedir name.
      ;; We defer computing this until the first time it's needed,

Chris.

RE: abbreviate-file-name on Windows seems incorrect

[Drew Adams]

> The value of HOME is cached the first time abbreviate-file-name is
> called, and never updated, using exactly the code you quoted here:
>
> > The code for `abbreviate-file-name' defines `abbreviated-home-dir' as
> > follows, in order to be able to "substitute `~' for the user's home
> > directory", as the doc string says:
> >
> > (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:
>
> If you look up 3 lines from that comment about the slash, you'll see:
>
>       ;; Compute and save the abbreviated homedir name.
>       ;; We defer computing this until the first time it's needed,

Right. I saw that (but forgot about it - thanks for reminding me).

I think that's a mistake. What's gained by that? We already saw what is lost
by it.

BTW, the comment about deferring computation seems off base. I don't see any
computation deferral, but I do see computation caching. That's what is
important (and wrong), I think: `abbreviated-home-dir' is computed only
once.

Re: abbreviate-file-name on Windows seems incorrect

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

> Please show your precise test case (in "emacs -Q").

On trying to reproduce my test, I'm getting different results (sigh).

Here's the test:

On Windows, before Emacs, in Cygwin bash:

$ echo $HOME
/Stephe
 
$ emacs -Q

---- in *scratch* -------
(getenv "HOME")
"C:\\Stephe"

(expand-file-name "~/foo")
"c:/Stephe/foo"

(abbreviate-file-name "/Stephe/foo")
"/Stephe/foo"

(abbreviate-file-name "c:\\Stephe\\foo")
"c:\\Stephe\\foo"

(abbreviate-file-name "c:\\Projects\\foo")
"c:\\Projects\\foo"


(setenv "HOME" "c:\\Projects")
"c:\\Projects"

(getenv "HOME")
"c:\\Projects"

(expand-file-name "~/foo")
"c:/Projects/foo"

(abbreviate-file-name "c:\\Projects\\foo")
"c:\\Projects\\foo"

----------

Now I'm getting the expected behavior from 'expand-file-name', but not
from 'abbreviate-file-name'. This is from

GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600) of 2007-01-06 on ACS1100007992

I have access to a Sun Solaris box:

GNU Emacs 21.4.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars) of 2005-09-21 on ra

-------
(getenv "HOME")
"/home/stephe"

(expand-file-name "~/foo")
"/home/stephe/foo"

(abbreviate-file-name "/home/stephe/foo")
"~/foo"

(abbreviate-file-name "/home/Projects/foo")
"/home/Projects/foo"


(setenv "HOME" "/home/Projects")
t

(getenv "HOME")
"/home/Projects"

(expand-file-name "~/foo")
"/home/Projects/foo"

(abbreviate-file-name "/home/Projects/foo")
"/home/Projects/foo"

---------

This is exhibiting the expected behavior for 'expand-file-name', and
the caching behavior for 'abbreviate-file-name'.

-- 
-- Stephe

Re: abbreviate-file-name on Windows seems incorrect

[Jason Rumney]

Drew Adams wrote:
> I think that's a mistake. What's gained by that? We already saw what is lost
> by it.
>   

What is gained is significant performance. What is "lost" is a contrived 
situation of the user's home directory changing from inside Emacs that 
does not really occur in reality.

Re: abbreviate-file-name on Windows seems incorrect

[Chris Moore]

Stephen Leake <stephen_leake@member.fsf.org> writes:

> (expand-file-name "~/foo")
> "c:/Projects/foo"
>
> (abbreviate-file-name "c:\\Projects\\foo")
> "c:\\Projects\\foo"

abbreviate-file-name is using string-match to see check whether
"c:\\Projects\\foo" matches the regexp "^c:/Projects\\(/\\|\\`\\)".
It doesn't, so no abbreviation happens.

It's the old MS-DOG confusion between \ and / again.

RE: abbreviate-file-name on Windows seems incorrect

[Drew Adams]

> > I think that's a mistake. What's gained by that? We already saw
> > what is lost by it.
>
> What is gained is significant performance. What is "lost" is a contrived
> situation of the user's home directory changing from inside Emacs that
> does not really occur in reality.

Can you describe the context and extent of the performance improvement? It
doesn't seem to me to be saving much computation, at a loss of generality,
contrived or otherwise. IOW, what is the use case that this is trying to
support?

I'm not so sure that a change of $HOME inside Emacs, followed by a call to
`abbreviate-file-name' is only contrived. But I admit that I don't have a
specific use case in mind to argue for undoing the optimization. I would
like to understand why the optimization is there, however.

Re: abbreviate-file-name on Windows seems incorrect

[Eli Zaretskii]

> Cc: Stephen Leake <stephen_leake@member.fsf.org>, miles@gnu.org,
>         drew.adams@oracle.com, emacs-devel@gnu.org
> From: Stephen Leake <stephen_leake@member.fsf.org>
> Date: Mon, 08 Jan 2007 03:44:09 -0500
> 
> Now I'm getting the expected behavior from 'expand-file-name', but not
> from 'abbreviate-file-name'.

`abbreviate-file-name' behaves as expected, it isn't supposed to be
handed backslashes as directory separators.  Try this instead:

  (abbreviate-file-name (expand-file-name "c:\\Stephe\\foo"))

Re: abbreviate-file-name on Windows seems incorrect

[Richard Stallman]

    What is gained is significant performance.

Can you check whether the efficiency gain is really significant in
practice?  If it is, I agree this optimization is worth keeping.
But I am not sure that this function is called often enough to make
a significant difference.

If it is not, we might as well make things more flexible by removing
it.

Re: abbreviate-file-name on Windows seems incorrect

[Jason Rumney]

Richard Stallman wrote:
> Can you check whether the efficiency gain is really significant in
> practice?
Compared with the current version of abbreviate-file-name, getenv seems 
to take a little more than twice as long to complete on my system. So it 
might be reasonable to expect the time for abbreviate-file-name to 
triple if it is changed to calculate the value of HOME every time it is 
needed based on getenv alone. But abbreviate-file-name seems to do other 
things as well involving directory-abbrev-alist, which may be much more 
significant if we also need to repeat those because of the change.

> But I am not sure that this function is called often enough to make
> a significant difference.
>   
Possibly not. But I'd prefer not to consider such changes now.

Re: abbreviate-file-name on Windows seems incorrect

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Stephen Leake <stephen_leake@member.fsf.org>, miles@gnu.org,
>>         drew.adams@oracle.com, emacs-devel@gnu.org
>> From: Stephen Leake <stephen_leake@member.fsf.org>
>> Date: Mon, 08 Jan 2007 03:44:09 -0500
>> 
>> Now I'm getting the expected behavior from 'expand-file-name', but not
>> from 'abbreviate-file-name'.
>
> `abbreviate-file-name' behaves as expected, it isn't supposed to be
> handed backslashes as directory separators.  Try this instead:
>
>   (abbreviate-file-name (expand-file-name "c:\\Stephe\\foo"))

Right, that behaves as expected.

And 'abbreviate-file-name' caches $HOME on the first call. Which I
agree is the wrong thing to do.

Sorry for the confusion.

-- 
-- Stephe

Re: abbreviate-file-name on Windows seems incorrect

[Stephen Leake]

Jason Rumney <jasonr@gnu.org> writes:

>> But I am not sure that this function is called often enough to make
>> a significant difference.
>>
> Possibly not. But I'd prefer not to consider such changes now.

That makes sense. But how about mentioning the caching of $HOME in the
doc string?

-- 
-- Stephe

Re: abbreviate-file-name on Windows seems incorrect

[Richard Stallman]

    > Can you check whether the efficiency gain is really significant in
    > practice?
    Compared with the current version of abbreviate-file-name, getenv seems 
    to take a little more than twice as long to complete on my system. So it 
    might be reasonable to expect the time for abbreviate-file-name to 
    triple if it is changed to calculate the value of HOME every time it is 
    needed based on getenv alone.

Ok, that is enough reason to keep it the way it is.