From: Jim Porter <jporterbugs@gmail.com>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 51622@debbugs.gnu.org
Subject: bug#51622: 29.0.50; [PATCH] Abbreviate remote home directories in `abbreviate-file-name'
Date: Sat, 6 Nov 2021 09:38:59 -0700 [thread overview]
Message-ID: <c304dba8-30c5-7299-9726-856aecabd25c@gmail.com> (raw)
In-Reply-To: <87mtmhmh60.fsf@gmx.de>
On 11/6/2021 8:34 AM, Michael Albinus wrote:
> 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.
Ok, I can do that. I could even add caching for remote hosts if people
think it would help (it would probably improve performance, at least a
little bit). However, while I was looking at the implementation of
`abbreviate-file-name', I saw the following comment:
;; FIXME Is it even worth caching abbreviated-home-dir?
;; Ref: https://debbugs.gnu.org/19657#20
After looking over the explanation in that link, I decided to see what
the performance impact would be if I removed the caching. In my opinion,
the benchmarks suggest that the caching a small enough impact that the
brittleness with using the cache outweighed the benefits. However, I
don't feel strongly about that and if the cache should stay, that's ok
with me.
> 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:~")
I had thought about doing that originally, but when I looked into the
implementation to understand why home-dir abbreviation didn't work on
remote files, I figured the better long-term solution is to fix
`abbreviate-file-name' somehow. Then everyone benefits from the improvement.
> 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.
Is it a general rule that all Tramp-specific stuff goes into the Tramp
files, or would it be ok to write a patch that only touches files.el, so
long as the performance for local files isn't hurt? It wouldn't be
terribly difficult to replace `abbreviated-home-dir' with something that
handles multiple hosts, similar to `grep-host-defaults-alist'.
If I understand things correctly, `file-remote-p' can be non-nil for a
non-Tramp file if it has a file name handler that says so (e.g. if I
wrote my own package that handles some remote files in a different way
from Tramp). Maybe that's an argument in favor of changing this in
`abbreviate-file-name'. Then it works with any remote file. On the other
hand, maybe we need more protocol-specific information to do this
correctly, and I should do this inside Tramp...
Either way, I'll look at your patch and see how it compares; if doing it
that way ends up being better, then I'll try to implement something like
that. I see in your patch that you add to `directory-abbrev-alist'. Is
it ok to change a defcustom automatically like this? It seems to work in
my limited tests, but I thought defcustoms were for users to set
themselves. Should I come up with a different way to do this if I want
to merge it into Emacs?
> 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.
Thanks, I'll take a look.
next prev parent reply other threads:[~2021-11-06 16:38 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
2021-11-06 16:38 ` Jim Porter [this message]
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=c304dba8-30c5-7299-9726-856aecabd25c@gmail.com \
--to=jporterbugs@gmail.com \
--cc=51622@debbugs.gnu.org \
--cc=michael.albinus@gmx.de \
/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).