GNU bug report logs - #51622
29.0.50; [PATCH] Abbreviate remote home directories in `abbreviate-file-name'

Previous Next

Full log

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; [PATCH] Abbreviate remote home directories in
 `abbreviate-file-name'
Date: Fri, 5 Nov 2021 20:44:44 -0700

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

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

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.

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.

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

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.

[0001-Remove-automount-dir-prefix.patch (text/plain, attachment)]

[0002-Don-t-cache-abbreviated-homedir-for-abbreviate-file-.patch (text/plain, attachment)]

[0003-Abbreviate-home-directory-for-remote-files.patch (text/plain, attachment)]

[benchmark.el (text/plain, attachment)]

[benchmark-results.txt (text/plain, attachment)]

Previous Next

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