--- Begin Message ---
|
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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#65685: 29.1; Inconsistent behavior of quoted file name "/:~" across platforms |
|
Date: |
Sat, 14 Oct 2023 09:42:00 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Version: 29.2
Jim Porter <jporterbugs@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.
--- End Message ---