Re: convert-standard-filename

[Stefan Monnier]

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

Agreed.  I think that not only convert-standard-filename has drifted far
from its original purpose, but to fix it we need to define a new
function because too many callers require a behavior that's incompatible
with "the right convert-standard-filename".

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

I always thought you weren't completely convinced.  I'm all for it.
We do want to define it carefully, tho.  E.g. it should only operate on
names without performing any actual file/directory lookup.

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

The use in files.el is to generate a good backup file name, presumably
because "#foobar.perl#" would get turned into "#foobar.per" whereas we
prefer "#foobar.pe#".  I don't know how to do that with file-name-equal,
but admittedly, dos-8+3-filename is not sufficient to do it either: it
uses ad-hoc code in files.el.


        Stefan