From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#34343: [PATCH] Make project--find-regexp-in-files work with remote files Date: Tue, 7 Jan 2020 16:40:10 +0300 Message-ID: <7d46d704-6bcb-391c-64bb-4a443a88130d@yandex.ru> References: <2cfd53b2-8202-a321-a853-da0c949b0f15@yandex.ru> <6cf8bfa8-3873-d3db-9139-854359027e8a@yandex.ru> <87h81mqiq5.fsf@gmx.de> <0ff03b20-20d8-b6c0-c876-3fd525586180@yandex.ru> <87mubdps6s.fsf@gmx.de> <87blrsz3tf.fsf@gmx.de> <87blrrmht9.fsf@gmx.de> <87tv5fs6kf.fsf@gmx.de> <7a1e2e22-89d4-b8b9-6cd4-e6947436138c@yandex.ru> <87mub6uoa6.fsf@gmx.de> <87blrksxco.fsf@gmx.de> <81589ba9-0f93-599d-e55f-6605479454b0@yandex.ru> <87y2ukjuan.fsf@gmx.de> <10dbccdd-99e8-883b-01e6-e8d3bc1e195e@yandex.ru> <87k163fwsl.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="64347"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: =?UTF-8?Q?Felici=C3=A1n_?= =?UTF-8?Q?N=C3=A9meth?= , 34343@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 07 14:50:04 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iopFD-000CMK-EX for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Jan 2020 14:50:03 +0100 Original-Received: from localhost ([::1]:49108 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iopFA-0008JO-R4 for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Jan 2020 08:50:00 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50057) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iop6W-0002ZM-Fk for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2020 08:41:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iop6U-0002aF-0q for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2020 08:41:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41577) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iop6T-0002a2-Sh for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2020 08:41:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iop6T-0006np-R2 for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2020 08:41:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 13:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34343 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 34343-submit@debbugs.gnu.org id=B34343.157840442226091 (code B ref 34343); Tue, 07 Jan 2020 13:41:01 +0000 Original-Received: (at 34343) by debbugs.gnu.org; 7 Jan 2020 13:40:22 +0000 Original-Received: from localhost ([127.0.0.1]:47550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iop5q-0006mj-1s for submit@debbugs.gnu.org; Tue, 07 Jan 2020 08:40:22 -0500 Original-Received: from mail-lj1-f193.google.com ([209.85.208.193]:39894) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iop5n-0006mW-Ka for 34343@debbugs.gnu.org; Tue, 07 Jan 2020 08:40:20 -0500 Original-Received: by mail-lj1-f193.google.com with SMTP id l2so54752516lja.6 for <34343@debbugs.gnu.org>; Tue, 07 Jan 2020 05:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JeOQE0Id3bgV+gcUwXrKeSWFji13TyJVsLzqDnvhVYA=; b=fVMuNH+Itfn7QNArS/dtutkBp1J3k4QxDEP16Ho57Ju2Lx49lFE71VNfBTM/IMwmxj 0TgizfhIL3uqwNbYCYeCjIJtk2Kr2U+k/wLGQLu022BjQ92k4u8Lc89MoiAyhDkSkiFW qdQ1JofRwAWWRGGqOfu6f1QavTpIU22c0iToIiaskhBIHdUzwqB3sCkQFXULEkc4XUhM /Yt0kBC3sbdGqAG+7b0X2lm6d/V700Cqz+UnUN3a3Z9bYu2uLvDBax0zYm9NcfH6Xq5C y3jcdbxZitGlkvY81w4kRFZdKLDxWBLtJYz1JvnJr2eiI/++jzJ51ja+AOQxchzOD81q GkPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JeOQE0Id3bgV+gcUwXrKeSWFji13TyJVsLzqDnvhVYA=; b=k6GhDjS+tFMx5kJab1ilHzi52931za/QtJcy5/iAfonEK1ZpryzmrLlTEsZhP4UOBc ht9gZb6PAjtnapebFw5GRyhV88gCamJoHqmAPhMxDKuoNMEZaYJbmd+Rfv3Lvay4mLHR vwMdvHNw1Ibh25Tpzm8SrO+my98I0OU/JH+7gxljmuYgisP3j68jPAuTDkLOkUTaGw+J w5g1iSjSYg5BP+W7zAZYpLZDpvOnGsRZtL17yTUP7JZaUkWqqdoKTF30SmHs7kbQ8F0p A44acNPKj+Dn6oSrzJLzaVrt9y/A2oKotPyXfZ3hxVponOiO6EmlbJjrm/J8OxQH1UmW rZyw== X-Gm-Message-State: APjAAAXrc+cj+rpzsHQrj06IeFwMH/VDI8qfQMBkIeae2uF0ixEzukrb 3z+lZfjUCJd6mu/G/FW5IeUIs4rIhPg= X-Google-Smtp-Source: APXvYqzPZmlJwqh1Z27/HKrtwmWX/XeA4KOTMrqtDaMQJP3PZJUfVf1bVLQzg1c1Rt9hy8YEtLejCw== X-Received: by 2002:a2e:8197:: with SMTP id e23mr55960261ljg.250.1578404413388; Tue, 07 Jan 2020 05:40:13 -0800 (PST) Original-Received: from [192.168.1.142] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id y23sm30912228ljk.6.2020.01.07.05.40.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 05:40:11 -0800 (PST) In-Reply-To: <87k163fwsl.fsf@gmx.de> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:174299 Archived-At: On 07.01.2020 11:19, Michael Albinus wrote: > Dmitry Gutov 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.