Subject: bug#76023: 31.0.50; Observed behavior for substitute-in-file-name different from the doc string

From: Eli Zaretskii <[email-masked]>
Date: Mon, 03 Feb 2025 14:30:16 +0200

tags 76023 notabug
thanks

> From: arthur miller <[email-masked]>
> Date: Mon, 3 Feb 2025 03:12:39 +0000
> 
> According to docstring, text ending with '/~' should be descarded through
> the slash. Does not happen:
> 
> (substitute-in-file-name "some-string/~$HOME") => some-string/~C:\Users\arthur
> 
> However:
> 
> (substitute-in-file-name "some-string~/$HOME") => C:\Users\arthur

Yes.  Emacs on MS-Windows doesn't support the "~foo" notation, which
means "the home directory of user named 'foo'", because that's not
possible (or at least not easy) on Windows.  So on Windows we treat
the "~" character literally in those cases.  The above is the direct
consequence of that non-support.

> Which seems to be the promised effect. I guess it was a typo in
> the doc string and the code comment, otherwise it is a bug in the
> implementation. '//' works as advertised, so I guess it is just a typo in
> the doc string.

It isn't a typo in the doc string, because on Posix systems Emacs
behaves like the doc string says.  It is a common trait in
documentation Emacs not to describe too many details about the
idiosyncrasies of MS-Windows, especially in dark corners such as this
one.

> Furthermore, I find it a bit arcane, or at least unnexpected that I get
> a native namestring, instead of Emacs path, since other functions in the
> fileo.c return Emacs internal (unix-like) namestrings (thus far I have
> tested them).

That shouldn't matter, since Emacs can use both forward and
backslashes in file names.

> If it is a "feature" to get the native namestring, at least perhaps mention it?

It is a feature, but I don't think we want to mention it, because it's
Windows-specific, and because "~$HOME" makes very little sense on
Windows.