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

[Michael Albinus]

Jim Porter <jporterbugs@gmail.com> writes:

Hi Jim,

>> Thanks. However, I believe this test shall be called
>> `files-tests-file-name-non-special-file-abbreviate-file-name', like the
>> other non-special tests. And perhaps it shall be located prior
>> `files-tests-file-name-non-special-access-file'.
>
> Ok, done.

Thanks, I've pushed this to the master branch.

>> But it shouldn't be too hard to determine the defaults. We have
>> tramp-default-method{-alist}, tramp-default-user{-alist}, and
>> tramp-default-host{-alist}. All needed information is there.
>
> Right, that confirms what I suspected. I'll try to look into this in
> more detail later when I get the chance.

Would be interesting to see the result :-)

>>> I also attached a slightly-updated benchmark script as well as new
>>> results. Performance on local file names is the same as before the
>>> patch, and just slightly faster than before with Tramp file
>>> names. (Most of the performance improvements here happened in
>>> bug#51699, so I mainly wanted to maintain the current performance in
>>> this patch.)
>> Good, no regression :-)
>
> Fixing your comments below *did* regress performance for abbreviating
> Tramp file names compared to current master (it takes 1.47x as long
> now in the worst case), but it's still considerably faster than Emacs
> 28. I've attached updated benchmark results to show the difference.

Yes, that's the price we have to pay for clean code. I've explained why
it is needed.

However, the `tramp-file-name-handler' machinery has been grown over 20+
years. I'm not aware of useless stuff, but maybe it's worth to have an
*external* look at this wrt performance. Are you interested?

>> Well, I believe we can implement abbreviation also for other Tramp
>> backends, like in tramp-sudoedit.el. So it might be better to call this
>> handler `tramp-handle-abbreviate-file-name'.
>
> Done. I added this for the sudoedit and smb methods, since both support
> "~" expansion in `expand-file-name'. That *should* be sufficient, but
> I've never used either of those methods, so I could be wrong...

Thanks. I didn't find the time to check it for these methods, but it's
on my TODO for next days.

>> Please use `case-insensitive-p'. We don't know whether there will be
>> other implementation for this magic function in the future. And we shall
>> not bypass the checks in `tramp-file-name-handler', which are important
>> for parallel invocations of Tramp handlers.
>
> Fixed (same with `expand-file-name'). These changes slow things down a
> fair bit, but that's mostly due to checking for the right file name
> handler more often. Like I said above though, it's still a lot faster
> than Emacs 28 (thanks to bug#51699).

I've committed everything to master. Then I ran the regression tests,
and there were indeed some few surprises. All of them shall be fixed now
with my commit after yours.

I tend to close this bug report now, since everything reported has been
implemented. The open points don't need this bug anymore for progress.

WDYT?

Best regards, Michael.