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: Tue, 07 Jan 2020 10:19:54 +0100 Message-ID: <87k163fwsl.fsf@gmx.de> 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> 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="15090"; 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 Tue Jan 07 10:25: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 1iol6k-0001jH-UV for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Jan 2020 10:25:03 +0100 Original-Received: from localhost ([::1]:45208 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iol3Z-0006HL-Dk for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Jan 2020 04:21:45 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41741) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iol2u-0005n6-Bp for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2020 04:21:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iol2s-0004vC-OX for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2020 04:21:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41284) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iol2s-0004v4-GG for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2020 04:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iol2s-0004fd-CQ for bug-gnu-emacs@gnu.org; Tue, 07 Jan 2020 04:21:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 09:21:02 +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.157838880717863 (code B ref 34343); Tue, 07 Jan 2020 09:21:02 +0000 Original-Received: (at 34343) by debbugs.gnu.org; 7 Jan 2020 09:20:07 +0000 Original-Received: from localhost ([127.0.0.1]:47257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iol1z-0004e2-Du for submit@debbugs.gnu.org; Tue, 07 Jan 2020 04:20:07 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:45849) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iol1v-0004dS-J5 for 34343@debbugs.gnu.org; Tue, 07 Jan 2020 04:20:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578388796; bh=TbBy+fTGDMLXDPE6X0cftkP/L+dS2izOD+7h64jgyUM=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=McujEHkx84ZEF5GSNW+64ohE3yVivpXtkSJemMFDEDKapNj8vzOZ59IS+vgGHrKcm P//04aKhBvzFVUcUxBZCdc2p/zJoBW5Lg1vJcRyqJjiOQTlFGLGIHf3ylugyaagXzS WB3Q51QRGnPBJ+sgJ58ZkZdc4lxaW1Y563QbXFNk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from detlef.gmx.de ([212.91.238.170]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MkYbu-1jYZ9u2v3W-00m3Wt; Tue, 07 Jan 2020 10:19:56 +0100 In-Reply-To: <10dbccdd-99e8-883b-01e6-e8d3bc1e195e@yandex.ru> (Dmitry Gutov's message of "Tue, 7 Jan 2020 06:23:45 +0300") X-Provags-ID: V03:K1:yXgGym3yzfhjnhn5jdr6JoNWbjx8qlXKBERt1rQT53hRQ9Uo8Fo DUw8RsEqQvb0Hx0Am0KcOuH4EYBnwQmtTAQuqLOBBJOabKwXP8BTdm9v2G06AXvXWm+8Dx8 eunKGf4WfmmoDv4wT+e3mMxzrry4Zy/vGgq7iqGDLtIOulLdKdjm25g/2Bdo24iKCHrLKP1 cUiEFP8SSeACfewoJczDg== X-UI-Out-Filterresults: notjunk:1;V03:K0:g8a33bUw1Rc=:WzUYamLxg8TsMh3/ORhSjP z+msxvObu0r03FUdtEVwWHe5lPcDS9hZsxOjnzQl7vz8yDyiifXqE1YHpQTcVm2g9hzqrgsHE SeXaNe6AoxSm08Hl+FYshwybwHOV7RD3zn3rXD3ukshAUwjNkZiRPeUhnkflg4FRi0HpSonVS 90l/2y2z3h7nRioklhjhx9wOLc3EVeObp0IEQDE4kScy95Qt52IfnMY7f5Ziba6V8RONEtHg3 wm8xGmf5XgAsVGKWf5yvRTtx8OSVkMrGgtQ+34bexxSxo4Q5rgokR+96e17whQPqNLkBaj6qf CR4ZfbUFvCxJqD4Kwcrbo4YISDvLVFeyTvCDDMP736cTWn/L2BX+bEQA9YEEI6etnLjxUNZO4 LHixxRNQcZL+suWu+70yt1oJYp+8waTZ9FlAgVmzxu0WPUWoLQt4aPyFUHzndzoz4DJ6rmH9C 6sEtFMTngL83ekeBxc+z+vY6/PnUduyPegSw43OUo3ZZxXSNJKB5y7GxCwRzVbqQuhmItymDj Dzu5FsTiYK0UaA5yLjNnF6s48PzJBfy0HwVXTFKK1B0q5RX9FxPw9xhGkEonxdJhf24pe5iQK 1qzS8Jv/fIFvWpYRXRirlRNXLpyAX6FGBvakGcyF2sS1XkWbrb28B9Jv8y9AjqjZTWbIAIuKh 4QXP2p5blagnr8+UgjB646n3s5oxPiEn1A66KhSRu9ZuVrI28M4qBBhQQcNkRd5hY/V/jGqW3 CEwNQW7f7gLk7kwEl52HkLOX7tXHXTKM8xFl/cjLeqvcBU/jQ0frBgLTyg25LNHn7puRo1II 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:174294 Archived-At: 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 :-) 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. >>>> 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 can use it, and I will if I can't convince you otherwise, but we > *can* keep operation both fast and generic at the same time, so... why > not, really? 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. >> No. file-remote-p must pass the whole machinery. It isn't called only >> for your use case. > > Hence the double check which verifies that the second argument is > 'localname'. > >> And if we start such bypassing for a file name operation, we will end i= n >> 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. > > 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. 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. >> In general, there's no problem calling tramp-file-name-handler, because >> the remote operations take much more time. This machinery is neglectabl= e >> 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. >> 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. > > Not in the case of the new proposed use in project.el either. > > Anyway, the idea is only to do that where necessary to squeeze just a > little bit of more performance in places that don't need to protect > match data. I'll check today how I could remove save-match-data. 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. Best regards, Michael.