From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#34343: [PATCH] Make project--find-regexp-in-files work with remote files Date: Mon, 06 Jan 2020 19:48:00 +0100 Message-ID: <87y2ukjuan.fsf@gmx.de> References: <87r2bt1tio.fsf@gmx.de> <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> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="118153"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: =?UTF-8?Q?Felici=C3=A1n_?= =?UTF-8?Q?N=C3=A9meth?= , 34343@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 06 20:09:08 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 1ioXkQ-000UZk-C3 for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jan 2020 20:09:06 +0100 Original-Received: from localhost ([::1]:58450 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioXkO-000145-L2 for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jan 2020 14:09:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53447) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioXR1-0007Bb-F7 for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 13:49:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ioXR0-0005Gd-5x for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 13:49:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40830) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ioXQz-0005G4-RM for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 13:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ioXQz-0004mW-Qj for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 13:49:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 18:49: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.157833649118317 (code B ref 34343); Mon, 06 Jan 2020 18:49:01 +0000 Original-Received: (at 34343) by debbugs.gnu.org; 6 Jan 2020 18:48:11 +0000 Original-Received: from localhost ([127.0.0.1]:46803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioXQB-0004lM-8B for submit@debbugs.gnu.org; Mon, 06 Jan 2020 13:48:11 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:34423) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioXQ8-0004l8-Ot for 34343@debbugs.gnu.org; Mon, 06 Jan 2020 13:48:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578336482; bh=YL5rixXXXOdpotGdgQk2PxB+FgkFR43pOJOxS+r71+4=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=LfexqtqRL1QRJdtuDW5HGAQVxInFFzvsRfFm0pqTmRh5RgQZs448f4qevWOPpS291 LOlKRZyzCqwvQt2xcMvlP4Rz1jVWL2e4NMc/KCOEZUtzxsYh37gtXTlt2EmnsVpp0w pKrFWN9E9u7gapq+HV/2Meg9t2DgIINrsk0x93Vo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from detlef.gmx.de ([212.86.57.241]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N9MpS-1jkow146rc-015HKZ; Mon, 06 Jan 2020 19:48:02 +0100 In-Reply-To: <81589ba9-0f93-599d-e55f-6605479454b0@yandex.ru> (Dmitry Gutov's message of "Mon, 6 Jan 2020 17:33:06 +0300") X-Provags-ID: V03:K1:la/F7g36LKdBGqidJ2BiqcwdudRUNcwAd5OOBA/NSBEI1IsAn1v 02L7RIkuJzDIPQ6PlqsotaO3uI1ZCNmEyyetyaiKum0hWY/Gp4sCs4gh0XpOZKJybqEQr8S 27q9mmy5SKdLaiwEQARPu8kMxWpuCjuuj1fIcprWdkQ1CKTZCa0n4rs0kjjrwWBEbz9r3s1 ZkQSLSnnT6Sh7lR+DDxLA== X-UI-Out-Filterresults: notjunk:1;V03:K0:fF1lxH9ysRo=:Hwtb2uYKIG3CVeKVKkQMz6 4jw1Moe9ZpfX+wSOt56hkGXEgsQ6++OGPRoz0xETFHi5tP3vlpqsmOyQHW0aqOUySEzYYMXwq d7lkAD1UOZHEleAczIh1ojxPU48de95p9qDIypFoxFX3INRQHU2sZ+UkkZM2DBrZ8+5oE/97+ k2Bvpr8d9NEWtPRdnF86imgbuMsEgpwBsRyk5rTnh0WYNEUmVoe5Nai3t6SPy1t0gdvyufuRJ hN0+Sk6fQrLTGqJm5/ampk2BgomGScbf3E7Ls45TIpsrPVwMdNwcEVbPmEgk0vhS7KB5sfCkR SFCeqo0F9kp33mqZek08u2bM5z3yNjKBI3spmWu9NClHdaM39BiMktLEvAvtEa1tNQFLJC62T 2Fed72Ks2c8c7XnJpKHH+sYhmkqhuXHXOdlhSnWrRjuq7zmdE0V0fwMuxeX7HZOxI46bYOxcf Ptau3l27NGGqJfHvceHuTtMdAE844mHCBlz474qdmC7yuWYzN1Lzdff0Ld1Gf11eYxJC0pObD zWxtjznWWPqLfrIfioOpZ9y2TuXFIsohHHZRyPvAzoJ8VLRAV8HYfN46rcKNmaX3HcNaXoJr0 59LSL5q12/fsUqYc/bTfJIzy8G30J+t9nw1PHboXSMt696Ji1W60l7l72VI6JY8U8cVasgkfE HjCcRtCKtfD61+zHP9pw9qqXPNJ5+3eyDZp7pY1l/iTnvLcHA63fEENrC9gCJE8Cm3m0tWCjd kYjOOQuZ43QqHa4M8Z6kxkjnD+E1LZ+r1OV9jI8LfgDHw9B/+ytmu4iq1j7GnzzjvKpkCCdU 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:174258 Archived-At: Dmitry Gutov writes: > Hi Michael, Hi Dmitry, > As I've shown before, the generic dispatch is far from being the > bottleneck at the moment. tramp-file-name-handler doing a lot of > unrelated work is what takes the most time. It might be unrelated to yozur use case. But tramp-file-name-handler is the central heart of Tramp's file name handling. It ensures that the proper function is called; that a Tramp subpackage is autoloaded if needed; that there are no blocking situations due to simultaneous invocations from timers, filters, sentinels; that there are no unintended infloops; that Tramp events and errors are caught etc pp. In the Tramp repository, it is also responsible for thread handling. All of this must be applied for every file name operation, also for file-remote-p, even if you don't need some of this in your use case. >> 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 could use it like this, sure, but we can have a significant > performance improvement and keep the generic-ness at the same time. > > The simplest option is below. It works fast enough in my testing (*); > a bit slower than calling tramp-file-local-name directly, but not by > much. Certainly much faster than the current state of affairs. > > It's a bit messy, but I'm not sure how to structure the resulting > function best. There are several ways, though. What do you think? No. file-remote-p must pass the whole machinery. It isn't called only for your use case. 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. 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. > P.S. BTW, I think our convention is not to call save-match-data unless > obviously required. If the caller needs to save the match data, it > will use it itself. 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. Well, I will analyze all these calls, and maybe there are only one or two places. In this case I can remove save-match-data from the function, and apply it directly where needed. Let's see. Best regards, Michael.