GNU bug report logs - #65685
29.1; Inconsistent behavior of quoted file name "/:~" across platforms

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jim Porter <jporterbugs <at> gmail.com>
Subject: bug#65685: closed (Re: bug#65685: 29.1; Inconsistent behavior of
 quoted file name "/:~" across platforms)
Date: Sat, 14 Oct 2023 07:43:03 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 65685 <at> debbugs.gnu.org.

-- 
65685: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65685
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 65685-done <at> debbugs.gnu.org
Subject: Re: bug#65685: 29.1; Inconsistent behavior of quoted file name
 "/:~" across platforms
Date: Sat, 14 Oct 2023 09:42:00 +0200

Version: 29.2

Jim Porter <jporterbugs <at> gmail.com> writes:

Hi Jim,

> I think this works now, thanks. (Note that I just eval'ed the new
> version of 'tramp-sh-handle-expand-file-name' on MS-Windows to test
> things out, since I don't have a build environment set up on my
> MS-Windows system.)
>
> So with the patch you merged to Tramp, plus your other one for
> "lisp/files.el", I think this is all working consistently now.

Thanks for the feedback, I've pushed it to the repositories. Closing the bug.

Best regards, Michael.

[Message part 3 (message/rfc822, inline)]

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms
Date: Fri, 1 Sep 2023 12:22:09 -0700

To see this in action, run 'emacs -Q "/:~"' on both GNU/Linux and 
MS-Windows.[1] On GNU/Linux, this opens a dired buffer for the user's 
home directory. On MS-Windows, it opens a buffer for a new file named tilde.

According to the Emacs manual:

> ‘/:’ can also prevent ‘~’ from being treated as a special character
> for a user’s home directory. For example, /:/tmp/~hack refers to a
> file whose name is ~hack in directory /tmp.
I'd interpret this to mean that the MS-Windows behavior is correct. 
However, the example doesn't specifically say what should happen when 
the tilde comes immediately after the "/:". On the very rare occasions 
you might need it, you can always spell "a file named tilde in the 
current directory" like "/:./~".

This is relevant to some future Eshell changes I'm considering[2], where 
(I think) I'd like "/:~" to mean "the user's local home directory, even 
when default-directory is remote". In light of that, my selfish 
preference is that we keep the GNU/Linux behavior and standardize it 
across all systems. However, we could standardize the MS-Windows 
behavior instead; I'd then just have to call out the different Eshell 
semantics in the Eshell manual.

[1] You can see this inconsistency with other commands too, like "M-x cd 
RET /:~ RET".

[2] https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01244.html

Previous Next

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