unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





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