From: Michael Albinus <michael.albinus@gmx.de>
To: Jim Porter <jporterbugs@gmail.com>
Cc: 51622@debbugs.gnu.org
Subject: bug#51622: 29.0.50; [PATCH] Abbreviate remote home directories in `abbreviate-file-name'
Date: Sat, 06 Nov 2021 16:34:47 +0100 [thread overview]
Message-ID: <87mtmhmh60.fsf@gmx.de> (raw)
In-Reply-To: <5ac0b5f3-302c-2f96-771c-8d38088aa573@gmail.com> (Jim Porter's message of "Fri, 5 Nov 2021 20:44:44 -0700")
[-- Attachment #1: Type: text/plain, Size: 4068 bytes --]
Jim Porter <jporterbugs@gmail.com> writes:
Hi Jim,
> Currently, `abbreviate-file-name' abbreviates home directories, but
> only for the local system. For example:
>
> $ emacs -Q
> M-: (abbreviate-file-name "/home/jim/src") RET
> ;; => "~/src"
> M-: (abbreviate-file-name "/sshx:localhost:/home/jim/src") RET
> ;; => "/sshx:localhost:/home/jim/src"
>
> It'd be nice to abbreviate TRAMP home dirs, especially for the buffer
> list, where the long length of TRAMP paths means that I often just see
> the same leading bits of the paths repeated in the File column. As a
> result, it can be hard to tell the exact file it refers to. (Of
> course, as a workaround, I could just widen the window.)
Nice idea :-)
> Attached is a patch series to do this, but the patches probably
> warrant some explanation. First, I removed `automount-dir-prefix';
> it's been obsolete since 24.3, and it would have made implementation
> of the second part more complex.
This is not related to the problem, and it isn't needed because I
propose to skip your second patch (see below). Personally I have no
opinion about, you might apply this patch if you believe it makes sense,
but independently from the feature request.
> Second, I removed the caching of the abbreviated home dir. Since
> adding TRAMP support means there are multiple home dirs (one per
> host), keeping the caching would have been fairly complex, and it's
> already the source of potential bugs (e.g. when temporarily setting
> HOME to something else). I did some benchmarking on this (see
> attached), and while it is indeed slower without the caching, I don't
> think it's worth keeping the caching around. The real performance cost
> comes from calling `abbreviate-file-name' with a TRAMP file (even
> before my patch), but abbreviating a local file is quite fast, even
> with a pathologically large `directory-abbrev-alist'. I also wrote a
> couple of unit tests to make sure this function works correctly.
I disagree. We shall keep the cached abbreviated-home-dir as *local*
home directory. Remote home directories shall be handled in Tramp, and
nowhere else.
This is a general design goal which I try to follow. Mixing Tramp needs
with other packages is good for trouble, and shall be avoided if possible.
> Finally, I added the actual TRAMP support. This has a pretty
> significant performance hit to TRAMP files. Looking at profiles,
> this appears to be because my patch calls both
> `file-name-case-insensitive-p' and `file-remote-p' on the TRAMP path,
> and these duplicate quite a bit of work. Is there a way to make this
> more efficient (e.g. by getting the file handler just once instead of
> twice)? It might also be useful to add some unit tests here, but I
> wasn't 100% sure how to do that with TRAMP paths (the tests in my
> benchmark actually open an SSH connection, so that probably won't work
> on all systems).
I believe there is a much simpler solution: Add the following entry
(derived from your example) to directory-abbrev-alist:
("\\`/sshx:localhost:/home/jim" . "/sshx:localhost:~")
The appended patch is a proof of concept w/o any systematic testing, it
is not ready for commit. You might use it in order to get the idea, and
to provide an applicable patch. It handles only tramp-sh.el; other Tramp
backends might need something similar.
Tramp tests could be added to tramp-tests.el. You'll see there a Tramp
mockup method which gives you the possibility to add a test w/o a
working ssh connection or alike.
> In addition to the patches, I've also attached a simple benchmark
> script that I used to measure the performance of these patches as well
> as the results from my system. The performance for local paths is
> still quite good I think, and even the worst-case scenario for TRAMP
> paths (abbreviating with a 500-item `directory-abbrev-alist') clocks
> in at 4.6ms per call. It'd be nice to make that faster, but maybe
> that's the best we can do if we want this feature.
I'm eager to see new figures with an adapted patch.
Best regards, Michael.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 768 bytes --]
diff --git a/lisp/tramp-sh.el b/lisp/tramp-sh.el
index 6f3b3245..974e3f3a 100644
--- a/lisp/tramp-sh.el
+++ b/lisp/tramp-sh.el
@@ -2723,6 +2723,14 @@ the result will be a local, non-Tramp, file name."
(format "cd %s && pwd" (tramp-shell-quote-argument uname)))
(with-current-buffer (tramp-get-buffer v)
(goto-char (point-min))
+ (add-to-list
+ 'directory-abbrev-alist
+ (cons
+ (concat
+ "\\`" (tramp-make-tramp-file-name v 'noloc 'nohop)
+ (buffer-substring (point) (point-at-eol)))
+ (concat
+ (tramp-make-tramp-file-name v 'noloc 'nohop) uname)))
(buffer-substring (point) (point-at-eol)))))
(setq localname (concat uname fname))))
;; There might be a double slash, for example when "~/"
next prev parent reply other threads:[~2021-11-06 15:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-06 3:44 bug#51622: 29.0.50; [PATCH] Abbreviate remote home directories in `abbreviate-file-name' Jim Porter
2021-11-06 8:06 ` Eli Zaretskii
2021-11-06 15:34 ` Michael Albinus [this message]
2021-11-06 16:38 ` Jim Porter
2021-11-06 17:41 ` Michael Albinus
2021-11-07 3:30 ` bug#51622: 29.0.50; [PATCH v2] " Jim Porter
2021-11-07 18:37 ` Michael Albinus
2021-11-08 4:54 ` Jim Porter
2021-11-08 15:58 ` Michael Albinus
2021-11-08 18:32 ` Jim Porter
2021-11-08 19:18 ` Michael Albinus
2021-11-14 2:10 ` Jim Porter
2021-11-14 14:43 ` Michael Albinus
2021-11-15 6:58 ` bug#51622: 29.0.50; [PATCH v3] " Jim Porter
2021-11-15 16:59 ` Michael Albinus
2021-11-16 1:14 ` Jim Porter
2021-11-16 11:43 ` Michael Albinus
2021-11-16 12:57 ` Michael Albinus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mtmhmh60.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=51622@debbugs.gnu.org \
--cc=jporterbugs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).