RE: file-truename, convert-standard-filename

[Drew Adams]

> > THEORETICALLY, one _always_ needs c-s-f, unless either (1) you know
> > that the file that is named exists or (2) you know _all_ of the
> > following: (2a) the file system being used, (2b) the file name being
> > used, and (2c) that the given file name is a valid one for the given
> > file system.
> 
> No, I think it should be more restrictive: you should use c-s-f if and
> only if the file name might not be valid on the current system, and
> where it would be a bug if that file name turned out to be invalid on
> the current system.

>From that and the rest of what you wrote, you seem to be speaking of a usage
guideline that is more restrictive based on PRACTICAL considerations.

The text you quoted was, in contrast, trying just to describe the cases that
THEORETICALLY could be problematic. It says nothing about practical guidelines:
what to do about such cases (avoid them by using c-s-f or not).

I was trying to paraphrase what Eli said when he was describing which cases
could be problematic. Those are (I think) the criteria he cited. They are
presumably the rationale behind the current use of c-s-f (e.g. in defcustoms).

But he also said that in practice such cases are marginal (rare). And you've now
added that even for some of those rare cases we don't care enough to protect
against an error.

It is a PRACTICAL matter whether the problematic cases are in fact rare (they
are, apparently). And it is a PRACTICAL matter whether some of the problematic
cases should be ignored (so that an error is raised) if they arise.

If the code doesn't know what the current system might be when it is run, then
c-s-f is needed IF you want to be sure there is no problem. The "IF" part is a
PRACTICAL choice.

(Of course, if the set of problematic OSes is known, then the code can test to
see whether the current OS is one of them - but I didn't notice such a test in
the current Emacs code.)

> In most cases, the first condition is already false: you generally get
> file names which you know are valid on the current system.

"Generally" as in most often? Sure. "Generally" as in you can depend on that to
be the case? No.

Again, that's the point I was trying to make in distinguishing theoretical from
practical considerations. If you don't know, then THEORETICALLY you need to call
c-s-f, that is, IF you want to play safe. IN PRACTICE, however, you might not
care.

I'm just paraphrasing what I understood from Eli. I don't claim either that I
understood him correctly or that what he said is right. ;-)

> Of the remining cases, most fail the second condition: for most 
> files that may not be valid, it's perfectly OK to signal an
> error if it turns out to be invalid, because it was a
> user-error to use that file name.

That's a legitimate point - and it's a design choice, i.e., a PRACTICAL matter.

By "THEORETICALLY", I was trying to describe the situations in which you
wouldn't know enough to determine whether the file name might be invalid - and
so c-s-f would be called for IF you wanted to play it safe.

If instead it makes sense to let an error be raised because of an invalid name,
that's a different story. That choice doesn't affect the criteria that define a
problematic case. Making such a choice is a PRACTICAL matter.

Eli was trying to help me understand both (a) the potential problem and (b) when
and whether it arises in practice. I had trouble understanding, because there is
a difference between the two. He seemed at first to be saying contradictory
things (you need c-s-f to protect against... vs you probably don't need c-s-f).

> So yes, the cases where c-s-f are needed are rare and mostly 
> "internal".

Got it. I won't need c-s-f at all.

I was confused because I ran across it in the doc, and from its description it
seemed to be something I would need in order to compare file names. I suggest
that we remove it from the manual and clarify the doc string, so that users who
run across it don't use it unnecessarily.

> > IN PRACTICE, however, the only real use-case is for
> > MS-DOS support, and in particular, only when the file
> > name is a literal string in Lisp code.