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

[Michael Albinus <michael.albinus@gmx.de>]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

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

As said, I have no opinion about this. However, we shall care Eli's
opinion, who dislikes such a change.

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

The general rule is, to keep all this specific handling away from
files.el and companions. Emacs has the concept of file name handlers,
and if there is something to be done special, a file name handler shall
offer an alternative implementation. This is true for remote file names
(packages tramp*.el, ange-ftp.el, url-handler.el) as well as for other
special handling like automatic compression/decompression of files
(jka-compr.el), GPG encryption/decryption (epa*.el), handling image
files (mage-file.el), handling of tar files (tar-mode.el) etc. Not every
file name handler must implement all "magic" functions, if there's no
specific implementation, the original function is used.

See (info "(elisp) Magic File Names") for the list of basic functions a
file name handler could offer its own implementation, currently these
are 75 functions.

> 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?

If we want to implement a general purpose solution, not only for remote
file names in Tramp, we shall add `abbreviate-file-name' to that
list. Different file name handlers could start to offer their own
implementation, for the other file name handlers the current default
behavior will be kept. Perhaps we shall go this way.

And the first candidate would be tramp-sh.el.

Best regards, Michael.