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

[Dmitry Gutov]

On 07.01.2020 11:19, Michael Albinus wrote:
> 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 :-)

I mean a new operation in terms of file handlers. As in the OPERATION 
argument to tramp-file-name-handler.

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

Just this:

(defun file-local-name (file)
  "Return the local name component of FILE.
This function removes from FILE the specification of the remote host
and the method of accessing the host, leaving only the part that
identifies FILE locally on the remote system.
The returned file name can be used directly as argument of
`process-file', `start-file-process', or `shell-command'."
  (let ((handler (find-file-name-handler file 'file-local-name)))
    (if handler
        (funcall handler 'file-local-name file)
      ;; Until all the implementations switch over,
      ;; not sure how long to keep the compatibility here.
      (or (file-remote-p file 'localname) file))))

And yes, if we were speaking only about Tramp, I wouldn't worry about 
keeping the operation generic.

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

Fair enough.

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

Well, if you like the following piece of code, I guess we could live 
with that.

      (setq files (mapcar
                   (if (tramp-tramp-file-p dir)
                       #'tramp-file-local-name
                       #'file-local-name)
                   files)))

By the way, I have no idea what to do about having tramp-tramp-file-p 
called twice.

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

OK.

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

That seems to hint that it doesn't need to be implemented in terms of 
file-remote-p.

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

It won't affect my use, but it sounds like a good idea either way.