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 06:23:45 +0300 Message-ID: <10dbccdd-99e8-883b-01e6-e8d3bc1e195e@yandex.ru> 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> <87y2ukjuan.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="270180"; 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 04:24:56 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 1iofUG-001877-2W for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Jan 2020 04:24:56 +0100 Original-Received: from localhost ([::1]:41636 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iofUE-0007xc-4I for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jan 2020 22:24:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37836) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iofTQ-0006wG-Na for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 22:24:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iofTO-0003FK-RI for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 22:24:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41149) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iofTO-0003FB-NM for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 22:24:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iofTO-0003V1-KG for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 22:24:02 -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 03:24: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.157836743513427 (code B ref 34343); Tue, 07 Jan 2020 03:24:02 +0000 Original-Received: (at 34343) by debbugs.gnu.org; 7 Jan 2020 03:23:55 +0000 Original-Received: from localhost ([127.0.0.1]:47121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iofTG-0003UV-JX for submit@debbugs.gnu.org; Mon, 06 Jan 2020 22:23:54 -0500 Original-Received: from mail-lf1-f67.google.com ([209.85.167.67]:41527) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iofTF-0003U6-2V for 34343@debbugs.gnu.org; Mon, 06 Jan 2020 22:23:53 -0500 Original-Received: by mail-lf1-f67.google.com with SMTP id m30so37801908lfp.8 for <34343@debbugs.gnu.org>; Mon, 06 Jan 2020 19:23:53 -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=RUhKGEbvkNMVZIXd60SwCniO9rW5xv6MJ422c8BKrH0=; b=o1redXSAGAROvox5pYMbh+WfTzPUzwnrCFgPXtyiDyTTvLejz9Cy8H/qY5mpaZ7qZS 40q4PZCHOeALHUPLTb1fKJGbBOX+0EVanHnMSUEpMrG79EzluuZseTpsJGAt/slFhoX4 gO+1a5cbul0k9ZI1eAeTeqHbpP4ctQuFjqy6Kz5Uf0RBhP5UB2fPtU7YSKPXcci6DWE9 DY1IHIG+vMqPtHAIvv0cpssntqwLzw8LfPpn7VBCxJdSEDQ6aAzWPsNFaL/Cb6EHVp/6 3i+ivZ0LOICrCX/3BYhPIIwX53a2riQAukSqWeB3r0qn+sLXxrsJSomusoPwKxnHo63/ BLzg== 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=RUhKGEbvkNMVZIXd60SwCniO9rW5xv6MJ422c8BKrH0=; b=Jrs1+/GBlmEAFp5w5N/wzCYdh4gDfVgWbcoa/9qH9/lF7oXzF7bhs1AThVpOb58k3N 8VPlo8fyZCSdq+PVvljcTg7zgAZ0cm3D0mCL7K8OQxrx/yIZ1x2mpQhwjXelX4b8XaV7 6Sm8mR1mp0un7EDTfBxzYRd6/TbOfuO6fgt+UK1PsIz/iKLODfG0p7VGMuPPe3D6GFyW 8jLVe7J9sPO1jG2qtONeTuXKIUdjVZTf8fakHVkOcvqklhQBuLwMmFbg3Y3/b4VJFiVy Z01bkO8l9w3N3REZGfQ0s+fgWboMsJ10u6rOLFTavXK9OC2FDvhui0TuMKdx702TPIzq A4ww== X-Gm-Message-State: APjAAAVC6/E6wKkSAd52zYNMrlkIc/rg4/JcffZ9p7KUoG+8jOaYUTi/ PPK+AskV9Y5n4FeVRbJho1GQeyMtJ7c= X-Google-Smtp-Source: APXvYqwfuAEfPTqbPrDGiyqLZsaqoBlA7++ROK4xvMAcdpMGEAgLXG91qf2hIcAVVHPxoRqSbxhhQw== X-Received: by 2002:ac2:430d:: with SMTP id l13mr62144165lfh.112.1578367426731; Mon, 06 Jan 2020 19:23:46 -0800 (PST) Original-Received: from [192.168.1.142] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id w20sm23873234ljo.33.2020.01.06.19.23.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jan 2020 19:23:46 -0800 (PST) In-Reply-To: <87y2ukjuan.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:174284 Archived-At: On 06.01.2020 20:48, Michael Albinus wrote: > 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. As far as I can tell, it's unrelated to 'file-local-name' altogether, not just my 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. 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. >>> 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? > 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 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. 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. > 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? >> 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. 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.