Re: convert-standard-filename

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

>> AFAICT, there are the following different needs:
>> - The original intention: convert a standard name such as "~/.emacs" so
>> it works everywhere.  The argument should come from within Emacs.
>> This should pretty much only be used with a constant argument.
>> Maybe (a big maybe) it can be used for things like generating
>> a filename from some other piece of data, but I think even that should
>> be discouraged in favor of `md5'.
>> - Take a filename from outside Emacs and convert it into something Emacs
>> can use internally.  Can do things like cygwin handling.  Can assume
>> that the provided filename is valid, so it doesn't need to be careful
>> to drop invalid filename characters.  Can convert backslashes into
>> slashes on Windows.
>> - Take an internal filename and convert it to something that can be used
>> outside of Emacs.  E.g. convert slashes into backslashes.  Again, this
>> can probably assume that the file name is already valid and doesn't
>> need to drop funny chars.
> Something like that.  There's also dos-8+3-filename, which is needed
> when one compares with string= internal file names with those found on
> disk, but that's DOS-specific, or maybe it can be merged into the last
> category.

How 'bout a file-name-equal, which could also try to account for
case-sensitivity?
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.


        Stefan