GNU logs - #76023, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#76023: 31.0.50; Observed behavior for substitute-in-file-name different from the doc string
Resent-From: arthur miller <arthur.miller@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 03 Feb 2025 03:18:02 +0000
Resent-Message-ID: <handler.76023.B.173855267618597 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 76023 <at> debbugs.gnu.org
From: arthur miller <arthur.miller@HIDDEN>
Thread-Topic: 31.0.50; Observed behavior for substitute-in-file-name different
 from the doc string
Thread-Index: AQHbdekLW2BNjNZZBkWqvVWO5b7Bvw==
Date: Mon, 3 Feb 2025 03:12:39 +0000
Message-ID: <DU2PR02MB10109B85FECBC25A5C6D7D7DB96F52@HIDDEN>
Accept-Language: sv-SE, en-US
Content-Language: sv-SE
msip_labels: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU2PR02MB10109:EE_|DB9PR02MB6633:EE_
x-ms-office365-filtering-correlation-id: f3e733f2-6960-4903-de2a-08dd44009e06
x-microsoft-antispam: BCL:0;
 ARA:14566002|15030799003|19110799003|8060799006|7092599003|15080799006|461199028|8062599003|440099028|3412199025|41001999003|102099032;
x-microsoft-antispam-message-info: 5Q2hOaeziRKE9z+9ww002f6UM8oTBgh5uk7GHrfFbbzn5EA3gqefXUXapuacAqPWbpj1O1COml+iJtlLRzCstAppaqVJ1r9snkAjCqrqajUJpNDqO6RxcXgytH5WrN8CcdwD4DY/Atkin44p0y2gm8FmJjE/uQzOUSa0p3vE+rw7YiFzZiwkQFN3qoGqMqFMxs2+drNDTP3EMbub4wZF2l80IfTaJs3uGTEnkGsGuzcWUL23hyhMagQI83Gy7JxRyOa9lPTVDwjewQg7TF9ktDSnaSJrPtbDNVtrP0Cx7nNw918582bMpLbN3x0lRDXYge99sLDHLw1H+7X1U92O11FTJgD/2r4SPm9+JE2yIyZslEGkdRxl/RocJb4cQ38bXYuuEeMW6FJO6zweJyYWJoRNaRNQFv3tDkEnW1vTCUsGcjUI9PJ6lUWRYkGF/563penRqghvPwF5OHH4siT5ef8hc4ScfdJEb4DYMiJlSmP9kgxoNq/FaP+1NmhvdUiUe7+ruu1+guUbjl8Zh6pze3uR7qBMiV3u710oqR4VrXiyuA9NbNdCjRH9LURMDo4ql+2Z3CBLWSinQ4gKLNEF+ieZPrrh2uzMooMLmcP3nIWG3BT+T7jRlEYL9/6c1ZnrxYPKzljmiRDS1LiZCLYAdsmWg71t/9E30zuXylAqFzZhxfeJwQBhhKvwl1cMHoleEeMSvSHR/EDKdnW27PsAh8cfgFZC/uMrgAkGteOmEVYS6vEpd/WyYHXANHDKTNrMF/OUEdfqIlsgkCq9+AGpUUVdiTiIb628tnTNsk9Wuvg5QA/xoJ+cwymPMp/zCP5Vsf/IaxwuTLThbmYZlISp4RADx41hgfns4iR4Sv9NZtDuMLH+2t+q3jYGLnpWq7nRO+bYNFwaA8itrSlc4sEadQl4bImcwyh5QbOu62GfL6pMmy84DmrF8/0nxhavtmK9eLb2EtWNBJCsWYgFajKA0endDC+i/umLN5N0NsvLhcDYR3GT9V0aTWuaJJqpeatbPBQ882VPh812Oc5taZIjf1mgCLa4MtfbG8sOQhpLO1hLA50Ol0d5Wmcf/SHbVBCepaEOte5uZI77VzFEJpRgDBGZu218F3udIuQcn3emQqnPk2LrbO+9NIfJD6RCEOi8SFY+ly0KSKd3K+LYJWXeHg==
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: xzIQrYPJdgcUT6VI5JUqS5GbuinLmBpvVPHVmuq3azkKy2WB0Sja6t/3T8/uaOUvHeaoBQqi8LC/C8ekTywcnyPYCFcgT5Kddljz+NWI5zzxe0FTcWN3xjFZlBWlqW+nGbBC1PmMXCne+hEU+1o0MSYf3FHQc7G9aIO7PaSPCSNXSFDksYZuFK2h5xIdXItz0Oo2k7akMpHU1bFLoYVLbJOnqQ1ANlpH3Ktfj8GHd/yjve9r7h5RTxmCyg9wTNLZrA+vevGK55t9KKGXXxOh7SHKVIgegP4s6I/FBAsd7LhFlPCBYfWmHUsIX+6o4tbpG5mVV6vhiaZOmy+x9eSNf8Oc8irlfb6mcUSq/LEv/7+2Gulc21AN8p+PUd43QRLSEHJDvr8KFusMirRA/TJ4HGej2S5LtZ3pNkRJ4c1GqtUmelmwz9pyKdENm7VivUDVIUe0rYJERP7mVInTMgnXd9CFAV9taT93Oyz/WN4RSXYBj3Op36Tj/DD70TpAoedDFp7gXwEO6tmCTQzcjvQqhHLXxWpoKsdAy8PYPVkIYKZRZTNltyHQmkh6vsHjS329oRnfSWEaWZsj8W3LnIeBFlD6sTM/9p9mwydiAV0phvXwwvTsg4SGSFE5DznDQb+ekzk3/QZ4x2w9j+KQrc4Y670t6cWZ9SpqwyFyE1rldEAF1J2L6u3R1GMPjkEdXk8N5W6xUYs99S7UNMMQqaXt7K0aufKoZIqFf3P+rP+Q1Y0t+k6wQqMnJV4LZKIZgIlPrugTjHLPISAcPuAyfUn4p1CoWifiO+RzbmkRd7CXwoeLq2KsTrh1eQQiuq5Lh/EcvM62Ej+Gy5UWbaMj6eTcvAMbUMDKzF2GFb+8ZttSEpM4vm4oL8X/JLSQiSRtCIRM4G382+mB/rL07B9cTTzwynZkl3c9yhAiavFucy/3NMf2RT5uSgB+ueJPU65vOswYpKWWAjHOgBmzsW7UA+VR0xVm5sSI+AlrTKb04GWSLNBoIHelVVmgtp0DVeNEQ8gr9rwnemk8LZeHxIKNlcewE5qgrfBp8+KC6p0aV59hvH9qagrOqaJXnk6pC3kVpcmYhK0bPxctpNKuPJgdmerjMv/FP79rZfggsaI4ptd5tp7hMIgEC/SFNbckyrj9nXn2oC2Nvw/tIuFOO3iaKTzhjc4OyLUxkUbR6zNxz/di8ahA1KKf6g5lTKo8IkUwfvDcC78OUh9VruHZB8YI+f7abGIRjXmZPzl1/T5Pmc1t3ec=
Content-Type: multipart/alternative;
 boundary="_000_DU2PR02MB10109B85FECBC25A5C6D7D7DB96F52DU2PR02MB10109eu_"
MIME-Version: 1.0
X-OriginatorOrg: sct-15-20-7828-19-msonline-outlook-12d23.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU2PR02MB10109.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: f3e733f2-6960-4903-de2a-08dd44009e06
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2025 03:12:39.8388 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR02MB6633
Received-SPF: pass client-ip=2a01:111:f403:d20a::3;
 envelope-from=arthur.miller@HIDDEN;
 helo=PA4PR04CU001.outbound.protection.outlook.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

--_000_DU2PR02MB10109B85FECBC25A5C6D7D7DB96F52DU2PR02MB10109eu_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

According to docstring, text ending with '/~' should be descarded through
the slash. Does not happen:

(substitute-in-file-name "some-string/~$HOME") =3D> some-string/~C:\Users\a=
rthur

However:

(substitute-in-file-name "some-string~/$HOME") =3D> C:\Users\arthur

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.

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).

(substitute-in-file-name "some-string~/$HOME/test") =3D> C:\Users\arthu/tes=
t

It can be fixed by wrapping into `expand-file-name', but that might or
might not be desirable (to expand from relative path).

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

--_000_DU2PR02MB10109B85FECBC25A5C6D7D7DB96F52DU2PR02MB10109eu_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
According to docstring, text ending with '/~' should be descarded through</=
div>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
the slash. Does not happen:</div>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
(substitute-in-file-name &quot;some-string/~$HOME&quot;) =3D&gt; some-strin=
g/~C:\Users\arthur</div>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
However:</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
(substitute-in-file-name &quot;some-string~/$HOME&quot;) =3D&gt; C:\Users\a=
rthur</div>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Which seems to be the promised effect. I guess it was a typo in</div>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
the doc string and the code comment, otherwise it is a bug in the</div>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
implementation. '//' works as advertised, so I guess it is just a typo in</=
div>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
the doc string.</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
Furthermore, I find it a bit arcane, or at least unnexpected that I get</di=
v>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
a native namestring, instead of Emacs path, since other functions in the</d=
iv>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
fileo.c return Emacs internal (unix-like) namestrings (thus far I have</div=
>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
tested them).</div>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
(substitute-in-file-name &quot;some-string~/$HOME/test&quot;) =3D&gt; C:\Us=
ers\arthu/test</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
It can be fixed by wrapping into `expand-file-name', but that might or</div=
>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
might not be desirable (to expand from relative path).</div>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Calibri, Helvetica, san=
s-serif; font-size: 12pt; color: rgb(0, 0, 0);">
If it is a &quot;feature&quot; to get the native namestring, at least perha=
ps mention it?</div>
</body>
</html>

--_000_DU2PR02MB10109B85FECBC25A5C6D7D7DB96F52DU2PR02MB10109eu_--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: arthur miller <arthur.miller@HIDDEN>
Subject: bug#76023: Acknowledgement (31.0.50; Observed behavior for
 substitute-in-file-name different from the doc string)
Message-ID: <handler.76023.B.173855267618597.ack <at> debbugs.gnu.org>
References: <DU2PR02MB10109B85FECBC25A5C6D7D7DB96F52@HIDDEN>
X-Gnu-PR-Message: ack 76023
X-Gnu-PR-Package: emacs
Reply-To: 76023 <at> debbugs.gnu.org
Date: Mon, 03 Feb 2025 03:18:03 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 76023 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
76023: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D76023
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#76023: 31.0.50; Observed behavior for substitute-in-file-name different from the doc string
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 03 Feb 2025 12:31:02 +0000
Resent-Message-ID: <handler.76023.B76023.173858582920319 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: arthur miller <arthur.miller@HIDDEN>
Cc: 76023 <at> debbugs.gnu.org
Date: Mon, 03 Feb 2025 14:30:16 +0200
Message-Id: <861pwfcisn.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <DU2PR02MB10109B85FECBC25A5C6D7D7DB96F52@HIDDEN>
 (message from arthur miller on Mon, 3 Feb 2025 03:12:39 +0000)
References: <DU2PR02MB10109B85FECBC25A5C6D7D7DB96F52@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

tags 76023 notabug
thanks

> From: arthur miller <arthur.miller@HIDDEN>
> 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.

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 3 Feb 2025 12:30:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 03 07:30:32 2025
Received: from localhost ([127.0.0.1]:38199 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tevax-0005Mu-L3
	for submit <at> debbugs.gnu.org; Mon, 03 Feb 2025 07:30:32 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:39634)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>)
 id 1tevat-0004ya-FN; Mon, 03 Feb 2025 07:30:27 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1tevan-0004VN-Hw; Mon, 03 Feb 2025 07:30:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=xI4v5LTtVlMXiGmwI/pTWv/1vRsDyJUNsR7qCSg20kE=; b=Kzl9+eLhoP51
 H/8Pmvah386b1lg64Hxh13DUtI+T56VcKaIdifZAWCKtw2zh79b+FiCnuEgGpBk51LVHfPeo5wC4O
 gZZXFO2QPYqz3qyEOeIl6rf8PzGdYkgQWTUhk/tztlzsY3SS7mrBg1t08RVshU0IvIowOreQNf1HO
 pEdn3T4aYIGsiVPbR5zK+YKlRfqo/VxRVbjEaqaT23O3oOfpEeKmvymrxEsflGNxC7RMWw+pnboG2
 Kbc5i5nXGcPJRQyrsTA780KSc1S7Lg3G2WeTJXy9WXy3af9THMmm2bDxUQ1sVYHB2MY++ezg84vmx
 cYcCcjKCGK8RWA0YkRbcJw==;
Date: Mon, 03 Feb 2025 14:30:16 +0200
Message-Id: <861pwfcisn.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: arthur miller <arthur.miller@HIDDEN>
In-Reply-To: <DU2PR02MB10109B85FECBC25A5C6D7D7DB96F52@HIDDEN>
 (message from arthur miller on Mon, 3 Feb 2025 03:12:39 +0000)
Subject: Re: bug#76023: 31.0.50;
 Observed behavior for substitute-in-file-name different from the doc
 string
References: <DU2PR02MB10109B85FECBC25A5C6D7D7DB96F52@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: control
Cc: 76023 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

tags 76023 notabug
thanks

> From: arthur miller <arthur.miller@HIDDEN>
> 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.

Last modified: Mon, 3 Feb 2025 12:45:02 UTC

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