Re: convert-standard-filename

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: sds@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 07 Aug 2011 11:33:53 -0400
> 
> >> But how should it decide what is relative and what is not, e.g. in the
> >> case of "c:/foo" (or worse "c:foo") mentioned in the docstring?
> > Why by file-name-absolute-p, of course ;-)
> 
> This would mean that the input is interpreted in an OS-dependent way.
> It would seem to make more sense to say that the arg to
> convert-filename-argument (or its new replacement) should be
> a Unix-style filename, i.e. "C:<foo>" is always interpreted as
> a relative file name, even under Window or DOS.

Although it makes sense, that would change the current semantics, and
probably break some existing code out there.

> How 'bout a file-name-equal, which could also try to account for
> case-sensitivity?

He-he, I was arguing for years that file names are not strings and
cannot be compared as strings.  Finally I have someone who agrees ;-)

There's also the case of 8+3 aliases of long file names on Windows, we
bumped into that some time ago (the value of temporary-file-directory
on Windows uses the 8+3 alias, because that's how Windows sets up the
environment variable).

> Hmm... I didn't check all uses of doc-8+3-filename, but at least the one
> in files.el can't be replaced by file-name-equal.

They all can.  dos-8+3-filename was introduced _only_ to be able to
compare and match file names as strings.