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.bugs Subject: bug#72300: project.el: detect newly created project contained within another Date: Mon, 30 Sep 2024 04:35:07 +0300 Message-ID: <1acc2892-24fe-41fd-802c-8c9ba78eddbd@gutov.dev> References: <87r0bh8cy7.fsf@gmx.de> <86mslssny9.fsf@gnu.org> <04986428-27b5-462d-8f89-139cd56ea117@gutov.dev> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------s053ZgMouh4gMNsVviLVZNP9" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31969"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 72300@debbugs.gnu.org, Eli Zaretskii , Federico Tedin To: Ship Mints Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 30 03:35:50 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1sv5KH-0008Ca-Mc for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 Sep 2024 03:35:50 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sv5K0-0005NB-NC; Sun, 29 Sep 2024 21:35:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sv5K0-0005N2-2n for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2024 21:35:32 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sv5Jz-0005Xa-Pe for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2024 21:35:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=FIszsfH4C7tq83uxDrJpU3TW83ShUx/i+QsRbTi2jiM=; b=QELqwDZPemlpwec819+ilPNdzUfBJ2uqTX+RQhDFYxse6I9/DWsIFhL2KMO+wTyqR4f0nYdtGYSparn9PLbFaqs0nWJj+K8NLz4UF8/QTzf8xiHQVQp5NrBmHFOXJJm1Mogjh7YpEOP0WK7A8t3bWaPHOSiGkFo4Jc5I9HXIi6RnHMbScq+n6ddFkgmVCzTKCngR76jHD/Tdbs3hT86trPYc37PnDlYrKxOu63ykAIejDvI9H04ojctQQQcc3bQczK/V7CBuEXkWURIjNNkszMYCR7lgWPSwnKc+iIGpkLbgpCRY7u2pR/xzvM7dWG9VBweDy+e9sMdSlxpvqiK9rw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sv5KV-0007mH-P1 for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2024 21:36:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Sep 2024 01:36:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72300 X-GNU-PR-Package: emacs Original-Received: via spool by 72300-submit@debbugs.gnu.org id=B72300.172766015529804 (code B ref 72300); Mon, 30 Sep 2024 01:36:03 +0000 Original-Received: (at 72300) by debbugs.gnu.org; 30 Sep 2024 01:35:55 +0000 Original-Received: from localhost ([127.0.0.1]:43445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sv5KK-0007k6-7p for submit@debbugs.gnu.org; Sun, 29 Sep 2024 21:35:55 -0400 Original-Received: from fhigh-a4-smtp.messagingengine.com ([103.168.172.155]:60147) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sv5KI-0007jK-2K for 72300@debbugs.gnu.org; Sun, 29 Sep 2024 21:35:51 -0400 Original-Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id 17830114014A; Sun, 29 Sep 2024 21:35:12 -0400 (EDT) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Sun, 29 Sep 2024 21:35:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1727660112; x=1727746512; bh=FIszsfH4C7 tq83uxDrJpU3TW83ShUx/i+QsRbTi2jiM=; b=dlPawC/L4YUfk6fOdqPRJD+g68 zp9J3UsEHq9Z9O00x8zYDpcIujN++h/pUjq5g+fWJ5vdTXP8HWNo0sRLMRl3vW4b BZ8qH+YS2onV4Lh+pj6JcboFAB9Z0SF3nACLJ8rCUUA6Idw20Z+hitb9MHWMlXc/ 9Qr+qG3KcYUG9vyRyAQDg7/plOIs0IzkxKFMT/P5G6IZgbTqn5uY/SiFaI57ySAS /+1pP6tvQJ1K8VVouWwJS+59GHU3RzlFOf2Wfw/PBnmCuRbpo28N8+RxMr4u6XNn fumFZv9N46Bz401BtosCyhxcp2rtJjDdcVRMSUCE4P5G9shJDqCtLnYrS6Sg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1727660112; x=1727746512; bh=FIszsfH4C7tq83uxDrJpU3TW83Sh Ux/i+QsRbTi2jiM=; b=F6JzJQIjAuc/CPGnM4IfyvG11DcVzbsGe/u1KyzfMEaK txwOID5liyWloUetkyok4HAOf0S/85+WPb+sAX2t3t5wVZlraf109gme6Y/EAjmC nimWFlzYL/nBAsRiOW7J/xrS0gyH8gVSg+EK0za8b3trlUULyDqweWhZj5ShnJ+0 ZHkLGcW6yQUhc3Ag1fhtWDZU7lvXuSGmbo977fhYtIR3240Bpn4RGmRykqKeeNmU E5BN557bnHKk8565dsTRtKsZEV1sMR3Ix6peSh/rEpEjGuIdkvE/QNvwE5jNR5v9 wl4aQkwcJwaT1x/54Zt0A4TeuMpm1yh4m+/INqgXLQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddugedggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurheptgfkffggfgfuvfevfhfhjgesmhdtreertddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeehleefudekudduveekieelgfeiffdvkefhkeeljeeu jeegueekveffkeejjeevheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep gedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepshhhihhpmhhinhhtshesghhmrg hilhdrtghomhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehf vgguvghrihgtohhtvgguihhnsehgmhigrdguvgdprhgtphhtthhopeejvdeftddtseguvg gssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 29 Sep 2024 21:35:09 -0400 (EDT) Content-Language: en-US In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292682 Archived-At: This is a multi-part message in MIME format. --------------s053ZgMouh4gMNsVviLVZNP9 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 13/08/2024 16:31, Ship Mints wrote: > A good step is awareness for users and invalidating the cache via > project-forget methods is a good idea. For posterity: making it a method of an object doesn't seem to work since the directory might have changed enough that it's not possible to recreate the project instance to call it on. > I'd also offer a direct function > to invoke to invalidate the cache for programmatic use. project-forget-project is a Lisp function which could be used both interactively and from code. Attached is a PoC/WIP patch which adds cache invalidation this way. Not entirely happy with the approach yet, but I'd like to checkpoint it here. > vc caching, longer term, may need to consider a few more complex use > cases such as git repos with both submodules that are considered > extensions of the base project and submodules which are not. A concrete > example I see often is a "mono repo" structure with core server and > library code but with web and mobile front end code in submodules that > are treated as part of the project proper BUT with submodules for > vendor/third-party code that are not. A question here would be which > parts of the tree belong to which cached vc root. Very tangentially, we've just added support for speeding up file listing for projects using "sparse index". That one's for a different structure and repos above certain size, though. > Another use case I see is working on many unrelated projects/repos > across a variety of clients all in the same Emacs session and with > perhaps 100+ buffers/files open (as I pretty much have right now), a 17- > element cache won't be sufficient? Should the cache be for parent > directories and not for file names? With files, it gets full fast. Mine > is full right now with files most of which share the same repo root and > some that don't. These are all internal details, but: * 17 is the default size, then it grows, * project-try-vc caches only directories, using its own key, * The rest of the data you're seeing is for files and their VC statuses, that's separate info. But indeed it's a bit too much intermixing, project-vc's cache should move to its own structure first. Stay tuned. > I have wondered whether an implementation would be > better as directory variables? Cache invalidation without timestamps > on .dir-locals.el files remain the same but directory variable treatment > might be more natural to Emacs users? Directory variables are a thing, but not in the same sense that file-local variables are, in particular there is no object to save a "directory local" to at runtime. --------------s053ZgMouh4gMNsVviLVZNP9 Content-Type: text/x-patch; charset=UTF-8; name="project-forget-functions.diff" Content-Disposition: attachment; filename="project-forget-functions.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvcHJvZ21vZGVzL3Byb2plY3QuZWwgYi9saXNwL3Byb2dtb2Rl cy9wcm9qZWN0LmVsCmluZGV4IDU5OWEzNTBlNWNlLi45Y2M3MDMzNWFmYyAxMDA2NDQKLS0t IGEvbGlzcC9wcm9nbW9kZXMvcHJvamVjdC5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy9wcm9q ZWN0LmVsCkBAIC0xOTMsNiArMTkzLDEwIEBAIHByb2plY3QtZmluZC1mdW5jdGlvbnMKICAg J3Byb2plY3QtY3VycmVudC1kaXJlY3Rvcnktb3ZlcnJpZGUKICAgIjI5LjEiKQogCisoZGVm dmFyIHByb2plY3QtZm9yZ2V0LWZ1bmN0aW9ucyAobGlzdCAjJ3Byb2plY3QtdmMtZm9yZ2V0 LWRpcmVjdG9yeSkKKyAgIlNwZWNpYWwgaG9vayB0byBjbGVhciBjYWNoZSBmb3IgYSBkaXJl Y3RvcnkgdHJlZS4KK0VhY2ggZnVuY3Rpb24gb24gdGhpcyBob29rIGlzIHBhc3NlZCBhIHN0 cmluZywgdGhlIGRpcmVjdG9yeSBmaWxlIG5hbWUuIikKKwogKGRlZnZhciBwcm9qZWN0LWN1 cnJlbnQtZGlyZWN0b3J5LW92ZXJyaWRlIG5pbAogICAiVmFsdWUgdG8gdXNlIGluc3RlYWQg b2YgYGRlZmF1bHQtZGlyZWN0b3J5JyB3aGVuIGRldGVjdGluZyB0aGUgcHJvamVjdC4KIFdo ZW4gaXQgaXMgbm9uLW5pbCwgYHByb2plY3QtY3VycmVudCcgd2lsbCBhbHdheXMgc2tpcCBw cm9tcHRpbmcgdG9vLiIpCkBAIC01OTksNiArNjAzLDEzIEBAIHByb2plY3QtdHJ5LXZjCiAg ICAgICAgICAgKHZjLWZpbGUtc2V0cHJvcCBkaXIgJ3Byb2plY3QtdmMgcHJvamVjdCkKICAg ICAgICAgICBwcm9qZWN0KSkpKQogCisoZGVmdW4gcHJvamVjdC12Yy1mb3JnZXQtZGlyZWN0 b3J5IChyb290KQorICAob2JhcnJheS1tYXAKKyAgIChsYW1iZGEgKHN5bSkKKyAgICAgKHdo ZW4gKHN0cmluZy1wcmVmaXgtcCByb290IChzeW1ib2wtbmFtZSBzeW0pKQorICAgICAgICh2 Yy1maWxlLXNldHByb3AgKHN5bWJvbC1uYW1lIHN5bSkgJ3Byb2plY3QtdmMgbmlsKSkpCisg ICB2Yy1maWxlLXByb3Atb2JhcnJheSkpCisKIChkZWZ1biBwcm9qZWN0LS1zdWJtb2R1bGUt cCAocm9vdCkKICAgOzsgWFhYOiBXZSBvbmx5IHN1cHBvcnQgR2l0IHN1Ym1vZHVsZXMgZm9y IG5vdy4KICAgOzsKQEAgLTE4NzUsNiArMTg4Niw3IEBAIHByb2plY3QtZm9yZ2V0LXByb2pl Y3QKIFBST0pFQ1QtUk9PVCBpcyB0aGUgcm9vdCBkaXJlY3Rvcnkgb2YgYSBrbm93biBwcm9q ZWN0IGxpc3RlZCBpbgogdGhlIHByb2plY3QgbGlzdC4iCiAgIChpbnRlcmFjdGl2ZSAobGlz dCAoZnVuY2FsbCBwcm9qZWN0LXByb21wdGVyKSkpCisgIChydW4taG9vay13aXRoLWFyZ3Mg J3Byb2plY3QtZm9yZ2V0LWZ1bmN0aW9ucyBwcm9qZWN0LXJvb3QpCiAgIChwcm9qZWN0LS1y ZW1vdmUtZnJvbS1wcm9qZWN0LWxpc3QKICAgIHByb2plY3Qtcm9vdCAiUHJvamVjdCBgJXMn IHJlbW92ZWQgZnJvbSBrbm93biBwcm9qZWN0cyIpKQogCkBAIC0xOTk5LDYgKzIwMTEsOCBA QCBwcm9qZWN0LXJlbWVtYmVyLXByb2plY3RzLXVuZGVyCiBwcm9qZWN0cy4iCiAgIChpbnRl cmFjdGl2ZSAiRERpcmVjdG9yeTogXG5QIikKICAgKHByb2plY3QtLWVuc3VyZS1yZWFkLXBy b2plY3QtbGlzdCkKKyAgOzsgQ2xlYXIgdGhlIGNhY2hlIGZvciBESVIgYW5kIGJlbG93LCBp biBjYXNlIG9mIHByaW9yIHZpc2l0LgorICAocnVuLWhvb2std2l0aC1hcmdzICdwcm9qZWN0 LWZvcmdldC1mdW5jdGlvbnMgZGlyKQogICAobGV0ICgoZGlycyAoaWYgcmVjdXJzaXZlCiAg ICAgICAgICAgICAgICAgICAoZGlyZWN0b3J5LWZpbGVzLXJlY3Vyc2l2ZWx5IGRpciAiIiB0 KQogICAgICAgICAgICAgICAgIChkaXJlY3RvcnktZmlsZXMgZGlyIHQpKSkK --------------s053ZgMouh4gMNsVviLVZNP9--