RE: file-truename, convert-standard-filename

[Drew Adams]

> Even after reading the ELisp node where it is documented?  Could you
> tell what else is missing?

Uh, no, because, as I said, I still don't understand it. When I do, you'll
understand better what is missing or could be stated better.

> > What do you mean by "embedded literal string" in the source 
> > code? If the Emacs source code has (defcustom foo ".emacs"...),
> > do I need to apply c-s-f to foo in order to compare its value?
> 
> Only if the other string is a name of a file that already exists in
> the filesystem.

I'm comparing arbitrary, unknown file names. I don't know the names ahead of
time, and I don't know whether they name existing files.

>From what you just said, I will always need to use c-s-f, since one of the 
>files
might be ".emacs" (assuming it appears in Emacs source code as an embedded
literal) and the other might be an existing file.

That's different from your first statement that probably just f-t would be
sufficient. I used (c-s-f (f-t FILE)), but you suggested that (f-t FILE) would
be sufficient.

But I've probably got this all wrong, because I still don't understand it. I
still haven't heard (or haven't understood, if in fact you've said it) what
c-s-f is _for_: what use cases. Perhaps you can give some useful examples of
calling it and why it's needed for those calls - what can go wrong if it's not
called in those cases.

> > And does "Emacs sources" apply only to code distributed with Emacs
> > or to any Emacs-Lisp source code?
> 
> The latter, of course.

So any occurrence of a literal string in any Emacs-Lisp (or C?) code? If that
particular name is used as a file name, then one needs to wrap c-s-f around it
when it is so used? That's hard to believe.

> > And you seem to say two things: a "file name embedded as a 
> > literal string" and "a name of a file mentioned in Emacs sources".
> > Is c-s-f needed for certain file names (e.g. those "mentioned" in
> > Emacs sources) or for certain strings (e.g. literal strings in
> > distributed source code) that name files?
> 
> ``Literal string'' is the main issue here.  That's why this function
> was introduced in the first place: to seamlessly take care of all the
> places in Emacs Lisp sources where there's a literal string serving as
> a file name, and that string might be an invalid file name on some
> filesystems.

I'm beginning to understand, I think.

It sounds like c-s-f is something to use at the point where the literal string
is introduced into the code - and only then. If code is written so that any
literal string that might be used as a file name is first wrapped with c-s-f
before being bound our assigned to a variable, and there are no other literal
occurrences of it, then one should be OK. Is that it?

What about a literal string that is not in code, but is provided by a user
interactively or constructed dynamically (e.g. (concat ".em" "acs"))? If a
prompt asks a user where to save his blahs, and he answers ".emacs.blah", does
code that handles that filename then need to wrap it with c-s-f? And does it
matter whether the file in question already exists (as was stated before)?

I'm guessing that the answers here are no and no, that it applies only to
strings in code and it has nothing to do with whether the files named already
exist. But please let me know.

> > IOW, is it about the name or the actual string object?
> 
> It's about the names that are valid on some systems, but not on
> others.

So it is _not_ the string that's important. So it is also not the fact that a
literal string is in code (as opposed to being entered or created dynamically).
(concat ".e" "macs") is just as problematic as ".emacs", and needs to be wrapped
with c-s-f. Is that it?

Very sorry, but as you can see, this is still not clear at all to me. You say
its the presence of a literal string that's problematic, then you say it's the
name itself that is problematic, since a file with that name might not be
possible on some system.

Every statement you make makes me think I understand a bit, until I reach the
next statement, which seems to say something different. I'm sure that once I
understand then all of the statements will make sense together, but so far they
do not, for me.

> > Does it matter whether it's (string= (file-truename 
> > ".emacs") (file-truename bar)) or (string= (file-truename foo)
> > (file-truename bar)), where foo's value is
> > ".emacs"? Is c-s-f needed in the former case but not the latter?
> 
> It is needed in the first case, if `bar' is the name of a file already
> existing in the filesystem, because on MS-DOS, `bar' could be "_emacs"
> instead.

But .emacs and _emacs could be two different files on MS-DOC, no? I'm not
familiar with MS-DOS - is a file named ".emacs" impossible (unlike Windows)?

> It _may_ be needed in the second case if one of `foo' or
> `bar' is a string whose value is ".emacs", while the other is the name
> of a file already existing in the filesystem.  It is _not_ needed if
> both `foo' and `bar' hold names of files already existing on
> filesystems of the same type.
> 
> > Obviously, I'm not yet understanding what this is about. 
> > Does it have something
> > to do with strings that are defined before Emacs gets dumped?
> 
> No, Emacs dumping is not the issue here, at least not directly.  For
> defcustoms, it's not an issue because a defcustom is evaluated again
> when a dumped Emacs starts.  So if the filesystem where it was dumped
> is different from the one where it starts, the name will be
> recomputed anew.

Hm. But there _are_ lots of defcustoms that use c-s-f. (I was mistaken about
defcustoms with f-t, but not c-s-f.)

I think that with just a little more help, especially some examples, I might get
it. But I'm not there yet. Some examples without it that are problematic, and
just what the problems are (bad consequences). And the same examples fixed to
use c-s-f. Thx.