Re: convert-standard-filename

[Lennart Borgman <lennart.borgman@gmail.com>]

On Sun, Aug 7, 2011 at 21:43, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>>> 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.
>> If we allow OS-dependent file names then does it not make more sense
>> to interpret them in the OS-dependent way? At least that seems much
>> more likely to make users surprised.
>
> The whole point of convert-standard-filename was to provide an
> OS-dependent file name from an OS-independent one (typically from
> a constant filename in a package).  So interpreting the input to this
> function in an OS-dependent way is wrong.

I would rather have it return a file name that fits the OS, regardless
of the file name that it is given. I.e. it should work both if the
argument is an Emacs standard file name or if it is an OS style file
name.

That does not fit the current doc string but the description in info:

 -- Function: convert-standard-filename filename
     This function alters the file name FILENAME to fit the conventions
     of the operating system in use, and returns the result as a new
     string.

If it does not work this way then file names read in some way must be
tested first to see if which type they are.