From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Speed up project-kill-buffers Date: Mon, 9 Aug 2021 06:01:54 +0300 Message-ID: <0335f070-7d3b-3ed5-703a-f0a8aaae2624@yandex.ru> References: <87mttcgnke.fsf@posteo.net> <871raoezl0.fsf@posteo.net> <86r1ihig9p.fsf@stephe-leake.org> <25bc7f1c-92e5-6b13-a6a4-d48b64b32ad3@yandex.ru> <86im3i76xa.fsf@stephe-leake.org> <86pmxmz45m.fsf@stephe-leake.org> <44b0b57f-27fd-d0b6-f350-5745375ff2a4@yandex.ru> <868s3whzyh.fsf@stephe-leake.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30597"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Cc: Philip Kaludercic , Stefan Monnier , emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 09 05:02:50 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mCvYu-0007mA-MG for ged-emacs-devel@m.gmane-mx.org; Mon, 09 Aug 2021 05:02:48 +0200 Original-Received: from localhost ([::1]:55406 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mCvYt-000594-J5 for ged-emacs-devel@m.gmane-mx.org; Sun, 08 Aug 2021 23:02:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48012) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mCvY9-0003mM-SH for emacs-devel@gnu.org; Sun, 08 Aug 2021 23:02:01 -0400 Original-Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:39842) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mCvY7-0003et-Kt for emacs-devel@gnu.org; Sun, 08 Aug 2021 23:02:01 -0400 Original-Received: by mail-wm1-x32c.google.com with SMTP id f9-20020a05600c1549b029025b0f5d8c6cso13440922wmg.4 for ; Sun, 08 Aug 2021 20:01:57 -0700 (PDT) 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=V0v8rMh6A0TvOSvsL4A+niA8cmJugbk0GqGAftHRaHo=; b=YrE2nU6B6khdHKsBuK2vK/9uk755rtPpZNNQ52bAkbzpvWV19NideTfFiSgMF5rjO1 PTOyHuzDxtyLe0unP3eDFlJKz9LlX2iJLUCDUilTp55JRi6CdH7fP/jj8Mox9FJW1jo/ 04VvXcAWCs4ygCvReMoA6EsZNbzT0EB8ssdh4MMlx6+e8nF2up6T4ZTZ005n6ourcO1c z/FQJQGitifKqHeLRHgVrbBbho6mA6PvibD2JCioAQR5twiO63A3hNUCpw7+WQa6CCKq Fq1JDWV81HzyTFAdBEJVXsykxteCIfktH4BSAvRSKGgUqbElbdXOeLFWyeUsRTzRiYDf ptww== 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=V0v8rMh6A0TvOSvsL4A+niA8cmJugbk0GqGAftHRaHo=; b=sLfZg9bE6dqINY4/mSgaX4DsMdc0fYTNNHXa4wFgS6iQQVwN/HQXYMZRJdAGkceB/W Fng64nI6sOf5+7LoN/OMkQn3WFEDj/tGaf/r5eRzVdYyiIfyhW/EWmEfb+wT9fxKgKqi PKELFjz3Tdsr98DtbrI9Iv3WBTDewU29XKV1gly0Yi4ccnYu+Vh9WhObZLpFIcFs1pXu SOruKdvbz2zU+CPOhaGt3mmF8FU5tacI4mMQGJXwfZEEg+g99uADrlHqeajp8A9yRLNU iTxi5hjz1T1SNvSAqM4dJcVb1sw3Btaa75n5y8lIEFbnAd8ogJlHRskdi2dK11PvQYkh XFZA== X-Gm-Message-State: AOAM531XWW+s0sU4GbxQUpV+o63AHfgThVlONxtfKo9z2J46rI6f94aj L1YGGEy9RHN+7hw9+H2EZTg3UtmBjAU= X-Google-Smtp-Source: ABdhPJwPIMyBKFuaQWhFh/gjifKjXwk5hD9bnNhn32i5umfmrRkLGvlFRB8o6pv1yTOGQ/8f4TxmbA== X-Received: by 2002:a7b:c452:: with SMTP id l18mr31312109wmi.22.1628478116719; Sun, 08 Aug 2021 20:01:56 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id e3sm4112925wro.15.2021.08.08.20.01.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Aug 2021 20:01:56 -0700 (PDT) In-Reply-To: <868s3whzyh.fsf@stephe-leake.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::32c; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32c.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:272222 Archived-At: Hi Stephen, I've posted a patch to https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49264#38 which should add the necessary flexibility, for your project backend to be able to list its buffers without being tied to the root dir. So far it just adds a generic called 'project-buffers'. On 30.05.2021 20:51, Stephen Leake wrote: > Dmitry Gutov writes: >> I'm fairly sure you don't want to close the buffers visiting the >> dependencies. > > Sometimes I do; I'm done working on ada-mode, and I transition to > working on my music database, closing all ada-mode related files. Other > times I don't; I found a bug in ada-mode, so I move to the wisitoken > library to run tests there, closing only the higher-level ada-mode > files. > > The point is that it is up to the user, to decide on a case by case > basis. If the distinction is indeed useful, maybe the change mentioned above can be followed with generic 'project-externals-buffers'. Either way, it seems you might prefer a new command like 'project-kill-other-buffers' (as opposed to 'project-kill-buffers'), which would kill all buffers (which satisfy project-kill-buffer-conditions, of course) that don't belong to the current project. >> Or if we do, that would be a globally acting modifier, and that piece >> of logic which we would add to project-kill-buffers would just see >> whether the buffer's default-directory is inside any of the "external >> roots", as defined by the backend. Would that work for you? > > I don't follow. What is the UI? How does the information given by the > user get passed to the backend? Only the backend can interpret > "dependencies". Yeah, scratch that. >> I'd rather we try to be more strict with semantics, if possible, and >> 'project-contains?' would only return t for buffers "inside" the >> project, not stuff that's outside but related to it (like external >> libraries, system includes, etc, which is what I'd like "external >> roots" to be targeted at). > > Then you need an "include-external-roots" arg to project-contains, since > sometimes that's what the user wants. For now it's project-buffers and (potentially) project-externals-buffers, for nicer naming and being able to implement in the vc backend in a performant fashion more easily (having predicate methods would require caching some information in the project instance between the calls). But project-contains-buffer-p and project-externals-contain-buffer-p are still on the table, if anybody feels strongly about that choice. >> If you want this change to happen, could you outline the cases when >> you would and would not use this capability? Personally, I'd probably >> never kill those buffers. > > I gave examples above. In general, if I'm switching to a project that > shares some files with the current one, I don't want to delete those > buffers. So the correct semantics would be "switching from project A to > project B; close all non-shared buffers". Sounds like 'project-kill-other-buffers' I described above. You might not even need to make a distinction between project contents and "externals" for this scenario (having 'project-buffers' return all pertinent buffers). But there can be other scenarios, I guess.