GNU bug report logs -
#34343
[PATCH] Make project--find-regexp-in-files work with remote files
Previous Next
Full log
Message #101 received at 34343 <at> debbugs.gnu.org (full text, mbox):
On 07.01.2020 11:19, Michael Albinus wrote:
> Dmitry Gutov <dgutov <at> 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.
This bug report was last modified 3 years and 303 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.