bug#34343: [PATCH] Make project--find-regexp-in-files work with remote files

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

Dmitry Gutov <dgutov@yandex.ru> writes:

Hi Dmitry,

> I believe it's an incidental detail that file-local-name is
> implemented through file-remote-p. Maybe we could also introduce a new
> operation as well.

I've done this, tramp-file-local-name :-)

But I wonder how you want to extract a file name's local part w/o
knowing how the remote part is identified. Again, we're not speaking
only about Tramp. If you have a better proposal for file-local-name
implementation I'm all ears.

>>>> In case you want to go your own path, I could provide you an own
>>>> tramp-file-local-name function, which bypasses this mechanism:
>> That's why I have provided this function. In order to avoid a call
>> of
>> file-local-name (which implies the call of file-remote-p).
>
> I can use it, and I will if I can't convince you otherwise, but we
> *can* keep operation both fast and generic at the same time, so... why
> not, really?

At least for Emacs 27.1 there won't be another solution. Eli is right,
when he rejects any substantial change to the emacs-27 branch before
Emacs 27.1 is released.

>> No. file-remote-p must pass the whole machinery. It isn't called only
>> for your use case.
>
> Hence the double check which verifies that the second argument is
> 'localname'.
>
>> And if we start such bypassing for a file name operation, we will end in
>> unmaintainability soon. Over the years, there has been often the
>> temptation to bypass this or that file name operation, similar to your
>> approach. Sometimes I even did, but soon I have reverted such
>> exceptions. Tramp isn't maintainable any longer, if we introduce such
>> coding style. Subtle errors you have no idea where they come from.
>
> It's up to you, but having an alist of exceptions should be both
> maintainable and readable. Like most other file handlers do (e.g.
> epa-file-handler) which maintain mappings of operations to functions.

I told you already that I have bad experience with such exceptions. All
of them I had to revert later, and I don't want to reopen this can of
worms.

epa-file-handler is different. In epa, there exist exactly one
implementation for a given file name operation; in Tramp you have
different implementations due to the subpackages. epa doesn't need to
care about timers, filters, sentinels, threads AFAICT. epa cares about
exactly two file name operations (insert-file-contents and
write-region), Tramp is responsible for 71 file name operations.

>> In general, there's no problem calling tramp-file-name-handler, because
>> the remote operations take much more time. This machinery is neglectable
>> then. Your use case is different, because you do not trigger any remote
>> operation.
>
> Would any use of file-local-name trigger a remote operation?

No, it shouldn't.

>> Well, as you might have seen with my recent commit in master, I
>> intend to use tramp-file-local-name internally. At some places it
>> seems to be necessary to protect match data.
>
> Not in the case of the new proposed use in project.el either.
>
> Anyway, the idea is only to do that where necessary to squeeze just a
> little bit of more performance in places that don't need to protect
> match data.

I'll check today how I could remove save-match-data.

OTOH, the version of tramp-file-local-name in master handles also the
case that the argument is NOT a remote file name, but a local
one. Needed in my Tramp internal use cases. I will backport this to the
emacs-27 branch, that you could also profit from if you want. It does
not cause a performance penalty for remote file names; an additional
`or' shouldn't hurt.

Best regards, Michael.