bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: bug#34343: [PATCH] Make project--find-regexp-in-files work with remote files
Date: Tue, 7 Jan 2020 16:40:10 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 07.01.2020 11:19, Michael Albinus wrote:
Dmitry Gutov <address@hidden> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]