From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ship Mints Newsgroups: gmane.emacs.bugs Subject: bug#72300: project.el: detect newly created project contained within another Date: Tue, 13 Aug 2024 09:31:02 -0400 Message-ID: References: <87r0bh8cy7.fsf@gmx.de> <86mslssny9.fsf@gnu.org> <04986428-27b5-462d-8f89-139cd56ea117@gutov.dev> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000098b72c061f909f83" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3667"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 72300@debbugs.gnu.org, Eli Zaretskii , Federico Tedin To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 13 15:32:46 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 1sdrdk-0000l0-TY for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Aug 2024 15:32:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sdrdX-00029Y-6s; Tue, 13 Aug 2024 09:32:31 -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 1sdrdV-00029G-FM for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2024 09:32:29 -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 1sdrdV-0004WD-5T for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2024 09:32:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=H9MW+kbw9nBDDfRWCGqjfgPVlDRsj5ukCulaZn7PdDU=; b=I6LKb242rw1VXyUU7vOICsD0af+F1F2j+LZuGSzDmf5k4+cEPTc2sto2Cp6eozzZZQUCWrX0cwYZSIuy7INsT5KQAKAMS58lFe5ce9qkgsWZcy9hWxIq+o7xHjk08PRguKmaorjCDFvQQcNLDTSAxnM2TFYAG4MfVkGqRiCEIw+nLKF3Qkr+7fns/cVyU7aNLwAcbHBAuXKfNm8GiZ67ar+MMtMeIfk+YMktAzc0HpLhMYeMdGFEm4dytwq7zGfV1POWrmwNnDbfTyNxoSPNbPi6H9rfm9mGZ34nk1c05wNYa4Y3QGsD/kGLGlYK5jdjCHknZtifQUrJzYmeuVZ1+w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sdre2-0008Bp-Cy for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2024 09:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ship Mints Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Aug 2024 13:33:02 +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.172355597631465 (code B ref 72300); Tue, 13 Aug 2024 13:33:02 +0000 Original-Received: (at 72300) by debbugs.gnu.org; 13 Aug 2024 13:32:56 +0000 Original-Received: from localhost ([127.0.0.1]:44611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sdrdv-0008BO-66 for submit@debbugs.gnu.org; Tue, 13 Aug 2024 09:32:56 -0400 Original-Received: from mail-vk1-f173.google.com ([209.85.221.173]:58616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sdrds-0008B7-Ug for 72300@debbugs.gnu.org; Tue, 13 Aug 2024 09:32:53 -0400 Original-Received: by mail-vk1-f173.google.com with SMTP id 71dfb90a1353d-4f6ba99286cso1729729e0c.0 for <72300@debbugs.gnu.org>; Tue, 13 Aug 2024 06:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723555874; x=1724160674; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=H9MW+kbw9nBDDfRWCGqjfgPVlDRsj5ukCulaZn7PdDU=; b=Wf20ocCFstW95do8GCdOGDUb6jt+XcSk8qGxsP/Y7IoaMjFMsoXD5uxuh1Fr/Ng/xY x0y3mkAvUtTxU+7yG2tiYFNlNGeRnXEJS0G3fIUG8heiyKlrcVfND1/ex4qMCbXb+Tb0 VIvfgjt8Aa92StxKax9MJTAhrJk20WaLyfgniALdwkfzvgxF9ZloumaXm5vAD5sb02vn c577khm3WA0SivYLewQBF9wp+gLg7PIjElxUpviA6VEteVsw5jXi+UMmBH7n002qn+iv to/AnVyqSCEUIvHut0Rv0tU3tnTvcd1o27SP+9KQS+fzKZxCogRuPan4y2LSZFSaPetX QUyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723555874; x=1724160674; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=H9MW+kbw9nBDDfRWCGqjfgPVlDRsj5ukCulaZn7PdDU=; b=NEa0ax49+UlNXz2JWi5LxPKlZJ4xp6Slpj/hRPnnJcVuy0RtAaM1WA79oM5ifPUMTd biUJrTWd8JP/pvaufUSixv6dUBTJGtuA4BJzjKFh0SZM+xeANZdWNCDNZBf442g9Bwhe vgjrF6Da4dZL92CVp4tZfy1o3PrW57rKs6/NNZHsN/rKfc/A7qHr0bwAoUm5bA2Ol1mV XSDt9lF7D401CmNhPARy//v2rV8fj52APPbAMjZqGOf2avTpbGQKjiZ58Rj9rkJvBmZO q/5SQVqLPM2lK/OJMoPNyYn4ZZztUqMtbXvrUbTWbxCANa+No2EiNxBdJN9fhfrcJ4/m OrbQ== X-Forwarded-Encrypted: i=1; AJvYcCXyl37odlypfafPC4w9WA5lzLytogXl19oipHQbXryJS7DthqONWCGNjs556uDy8Ugnu86Rlxm7kVqYRN+MWexbwPbFTC0= X-Gm-Message-State: AOJu0Yy5lZf/8O8XFLN5jqqdDrKUnhM5floFP7z70uo5F95mPg/XCVhF rt74mU5GxPdLKb+EKsjhtM7KjvvCdQmLbWEIo9S6yG5b8jNJjoydvhuYEnOk9iixiAKoIg5fSl6 MBfwM3IxV7RIQdNjHKh9MlWOvQ5U= X-Google-Smtp-Source: AGHT+IH+vN9gtLd3o+KwyV28ixkhJXbBzjBUkNIF0WhF7zVTLlc35O0C9YwZPRWoclyvPw2DH62kyNhJWpusb3dSAy4= X-Received: by 2002:a05:6122:7d0:b0:4f5:202b:6220 with SMTP id 71dfb90a1353d-4fabed8a7ddmr3889583e0c.0.1723555873598; Tue, 13 Aug 2024 06:31:13 -0700 (PDT) In-Reply-To: <04986428-27b5-462d-8f89-139cd56ea117@gutov.dev> 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:290077 Archived-At: --00000000000098b72c061f909f83 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A good step is awareness for users and invalidating the cache via project-forget methods is a good idea. I'd also offer a direct function to invoke to invalidate the cache for programmatic use. 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. 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. 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? -Stephane On Mon, Aug 12, 2024 at 9:43=E2=80=AFPM Dmitry Gutov wro= te: > Hi! > > On 05/08/2024 20:18, Ship Mints wrote: > > (vc-file-setprop dir 'project-vc project) in project-try-vc. There is n= o > > facility, public API or private, to clear the cache en-masse. One could > > reset the cache via clearing the vector vc-file-prop-obarray > > (setq vc-file-prop-obarray (make-vector 17 0)) in the absence of an API= . > > You can observe what's in your vc-file-prop-obarray for yourself before > > taking this action. > > That's right. One step toward that goal would be moving the cache to > some other data structure - possibly a tree-like one, to also be able to > short-circuit the upward directory searches. > > Cache invalidation is a sore point, though: the directory tree can > change behind the scenes outside Emacs, so unless the caching is > disabled the other complete solutions would rely on something like > filenotify. > > OT2H if we're okay with supporting only manual clears e.g. using 'M-x > project-forget-project' or 'M-x project-forget-projects-under', that > could be implemented easily enough. The current vc-file-prop-obarray > structure could be refreshed with a full scan. > --00000000000098b72c061f909f83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A good step is awareness for users and invalidating the cache via projec= t-forget methods is a good idea. I'd also offer a direct function to in= voke to invalidate the cache for programmatic use.

vc caching, longer term, may need to = consider a few more complex use cases such as git repos with both submodule= s that are considered extensions of the base project and submodules which a= re 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 i= n submodules that are treated as part of the project proper BUT with submod= ules for vendor/third-party code that are not. A question here would be whi= ch parts of the tree belong to which cached vc root.

Another=C2=A0use case I see is work= ing 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 m= uch 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 get= s full fast. Mine is full right now with files most of which=C2=A0share the= same repo root and some that don't. I have wondered whether an impleme= ntation would be better as directory variables? Cache invalidation without = timestamps on .dir-locals.el files remain the same but directory variable t= reatment might be more natural to Emacs users?

-Stephane

On Mon, Aug 12, 2024 at 9:= 43=E2=80=AFPM Dmitry Gutov <dmitry@g= utov.dev> wrote:
Hi!

On 05/08/2024 20:18, Ship Mints wrote:
> (vc-file-setprop dir 'project-vc project) in=C2=A0project-try-vc. = There is no
> facility, public API or private, to clear the cache en-masse. One coul= d
> reset the cache via clearing the vector=C2=A0vc-file-prop-obarray
> (setq=C2=A0vc-file-prop-obarray (make-vector 17 0)) in the absence of = an API.
> You can observe what's in your vc-file-prop-obarray for yourself b= efore
> taking this action.

That's right. One step toward that goal would be moving the cache to some other data structure - possibly a tree-like one, to also be able to short-circuit the upward directory searches.

Cache invalidation is a sore point, though: the directory tree can
change behind the scenes outside Emacs, so unless the caching is
disabled the other complete solutions would rely on something like
filenotify.

OT2H if we're okay with supporting only manual clears e.g. using 'M= -x
project-forget-project' or 'M-x project-forget-projects-under',= that
could be implemented easily enough. The current vc-file-prop-obarray
structure could be refreshed with a full scan.
--00000000000098b72c061f909f83--