Re: substitute-in-file-name and "$"

[Michael Albinus <Michael.Albinus@alcatel.de>]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Michael Albinus wrote:
>
>    `PC-do-completion' must do it, because the result is shown in the
>    minibuffer.
>
>    Or a file name like this: "$NEXT_HOP:/share$$", where $NEXT_HOP has
>    the value "/smb:next.hop.com". At least case (2) would be needed,
>    because Tramp file name handler could be activated only after applying
>    substitute-in-file-name to that file name.
>
> You can always double up all $'s if your function only has access to
> an already substituted filename.  (Putting a /: at the beginning would

But you even don't know that. My original problem came from the fact
that, if a user applies partial completion, the file name is already
substituted, and in the other case it isn't.

Meanwhile, I tend to regard it as a bug in `PC-do-completion', like
the others.

> be easier, but that could probably cause remote filenames to be
> considered local.)  All functions have to make clear in their
> documentation string what they are going to do to file names (if
> anything) and in which form they return them, if non-standard.  If
> they do not, that is a bug.  This is not madness.  It is completely
> obvious.  Functions need to say what they do.  People who use
> functions need to know exactly what they do, not more or less what
> they do.  It is usually easier to be able to find this out by reading
> documentation strings than by carefully reading through every single
> line of code of the function itself and of all indirectly called
> functions.

For file name operations, this would be even an implementation
restriction whether they can apply substitute-in-file-name, or not.

More general, it might be said under which circumstances it is
harmless to apply substitute-in-file-name (for local cases, where the
result of substitution isn't returned by the function), and when not.

> Sincerely,
>
> Luc.