GNU bug report logs - #76023
31.0.50; Observed behavior for substitute-in-file-name different from the doc string

Previous Next

Package: emacs;

Reported by: arthur miller <arthur.miller <at> live.com>

Date: Mon, 3 Feb 2025 03:18:02 UTC

Severity: normal

Tags: notabug

Found in version 31.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #10 received at control <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: arthur miller <arthur.miller <at> live.com>
Cc: 76023 <at> debbugs.gnu.org
Subject: Re: bug#76023: 31.0.50;
 Observed behavior for substitute-in-file-name different from the doc
 string
Date: Mon, 03 Feb 2025 14:30:16 +0200
tags 76023 notabug
thanks

> From: arthur miller <arthur.miller <at> live.com>
> 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.




This bug report was last modified 107 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.