GNU logs - #72300, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#72300: project.el: detect newly created project contained within another
Resent-From: Federico Tedin <federicotedin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 25 Jul 2024 19:55:02 +0000
Resent-Message-ID: <handler.72300.B.17219372941035 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 72300 <at> debbugs.gnu.org
From: Federico Tedin <federicotedin@HIDDEN>
Date: Thu, 25 Jul 2024 21:54:24 +0200
Message-ID: <87r0bh8cy7.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
UI-OutboundReport: notjunk:1;M01:P0:VIhis25tAAw=;Ftbf2n50yOGBego1VvsLaPu59xy
 otTQhcXF7Vw91MbKSVpeYyBpZNF0JwuDnCpNpB5loR+knGDplESQzNeRI1UTvztJeGo7Bh/wR
 FNS8rTfr9/fqWZbFD/AjiWU/P2stz5A0BxmWWeEM9K5OnRD60GyDA4HE4rSiJcKIjcuQRozg5
 G3zvIlTlGXsMKlggLePbpBPuEd4oa4h2PESGBoMRpSXhvt/H1pRZLso+39z9TR14Ov4qwsrNz
 LA+wAbCW2UTGl5AxbqHUWA4B7KPmYH3axWu52NBfBzgcs496qSgk4BYzWyvfHaMzxtDOV2qMy
 KxHdfqJ/yq8HKJfJe660VT8ijhq5Rq8cz6fAXbDOeRG/L2XPqami3XuIHqV/8dyz/GXiBsKd0
 hSFKx6JW+QQ77miUfkZ34LwteiGy7qPzYy+Z0dhlr6iZILOrk0Ks2P9AFHu6KWEnPontbJ0uH
 8NPP5LaRabBJiGLLf65yjH3E4Ona/WfN6KWGvpX7Jld1zzWEdK6SNejgV1LfSVKDa6fNnU9SQ
 srcX1hGGxTxyMUzCB6ISRH8nMcrDnWUqfQfM+JIWFeCw2eU2Um9tDu+ocVVhfnF4lzmPs8VVl
 1DoFwjsAGKAFl44rQFXvbnbVhPGbh9+6msBq2f7AKF0kmRvyEgqmvEkfaZzHs2Qvd9ae9Zgy1
 VolqbPaKMox/KHKLe39RDD8VIOdysTjCZB1Gh1xhkXo0mh/fJVUgc8oRUGf2SqHytZkvKkUad
 5uMcc/+UWmnnAbZ6gQ0cZnJmVJkjLSiK521Lsv201nJYBlliAGQCp23p5suzNkb2WpAU0BmRg
 rCegePUmE0+PEZdMBLN8sWHA==
Received-SPF: pass client-ip=212.227.17.21; envelope-from=federicotedin@HIDDEN;
 helo=mout.gmx.net
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

In Emacs master e56e4b345a2, `emacs -q`:

I'm having problems trying to make project.el detect a new project that
is contained in the directory of another project.

I have a directory called 'scratch' which contains a '.git' directory, a
file 'test.py' and a directory 'foo'. The 'foo' directory contains a
file called 'foo.py'.

~/scratch/
    .git/
    main.py
    foo/
        foo.py

If I open 'main.py', `(project-current)' evals to the expected: `(vc Git
"~/scratch")'.

If I open 'foo.py', `(project-current)' also evals to `(vc Git
"~/scratch")', which is expected.

However if now I cd into 'foo/' and run `git init`, then I would expect
project.el to now consider 'foo.py' to be in another project - `(vc Git
"~/scratch/foo")'. However, if I evaluate `(project-current)' when
visiting 'foo.py', I still get `(vc Git "~/scratch")'.

If I kill the buffer visiting 'foo.py' and open the file again, I get
the same result.

Interestingly, if I run 'M-x project-remember-projects-under' with
'~/scratch/foo' as path, it does inform me that the new project has been
found. However visiting 'foo.py` still results in `(vc Git "~/scratch")'
as the current project.

If I restart Emacs then the problem is solved; 'foo.py' is correctly
filed under project `(vc Git "~/scratch/foo")'.

The fact that this works correctly after restarting makes me think
that there must be some runtime state set up that is preventing the
desired behaviour to happen.

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Federico Tedin <federicotedin@HIDDEN>
Subject: bug#72300: Acknowledgement (project.el: detect newly created
 project contained within another)
Message-ID: <handler.72300.B.17219372941035.ack <at> debbugs.gnu.org>
References: <87r0bh8cy7.fsf@HIDDEN>
X-Gnu-PR-Message: ack 72300
X-Gnu-PR-Package: emacs
Reply-To: 72300 <at> debbugs.gnu.org
Date: Thu, 25 Jul 2024 19:55:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 72300 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
72300: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D72300
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#72300: project.el: detect newly created project contained within another
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 04 Aug 2024 08:17:01 +0000
Resent-Message-ID: <handler.72300.B72300.172275938923560 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Federico Tedin <federicotedin@HIDDEN>, Dmitry Gutov <dmitry@HIDDEN>
Cc: 72300 <at> debbugs.gnu.org
Date: Sun, 04 Aug 2024 11:15:58 +0300
Message-Id: <86mslssny9.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87r0bh8cy7.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
References: <87r0bh8cy7.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> Date: Thu, 25 Jul 2024 21:54:24 +0200
> From:  Federico Tedin via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> 
> In Emacs master e56e4b345a2, `emacs -q`:
> 
> I'm having problems trying to make project.el detect a new project that
> is contained in the directory of another project.
> 
> I have a directory called 'scratch' which contains a '.git' directory, a
> file 'test.py' and a directory 'foo'. The 'foo' directory contains a
> file called 'foo.py'.
> 
> 
> ~/scratch/
>     .git/
>     main.py
>     foo/
>         foo.py
> 
> 
> If I open 'main.py', `(project-current)' evals to the expected: `(vc Git
> "~/scratch")'.
> 
> If I open 'foo.py', `(project-current)' also evals to `(vc Git
> "~/scratch")', which is expected.
> 
> However if now I cd into 'foo/' and run `git init`, then I would expect
> project.el to now consider 'foo.py' to be in another project - `(vc Git
> "~/scratch/foo")'. However, if I evaluate `(project-current)' when
> visiting 'foo.py', I still get `(vc Git "~/scratch")'.
> 
> If I kill the buffer visiting 'foo.py' and open the file again, I get
> the same result.
> 
> Interestingly, if I run 'M-x project-remember-projects-under' with
> '~/scratch/foo' as path, it does inform me that the new project has been
> found. However visiting 'foo.py` still results in `(vc Git "~/scratch")'
> as the current project.
> 
> If I restart Emacs then the problem is solved; 'foo.py' is correctly
> filed under project `(vc Git "~/scratch/foo")'.
> 
> The fact that this works correctly after restarting makes me think
> that there must be some runtime state set up that is preventing the
> desired behaviour to happen.

Dmitry, any comments or suggestions?

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#72300: project.el: detect newly created project contained within another
Resent-From: Ship Mints <shipmints@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 05 Aug 2024 17:20:02 +0000
Resent-Message-ID: <handler.72300.B72300.172287838421799 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Dmitry Gutov <dmitry@HIDDEN>, Federico Tedin <federicotedin@HIDDEN>, 72300 <at> debbugs.gnu.org
MIME-Version: 1.0
References: <87r0bh8cy7.fsf@HIDDEN> <86mslssny9.fsf@HIDDEN>
In-Reply-To: <86mslssny9.fsf@HIDDEN>
From: Ship Mints <shipmints@HIDDEN>
Date: Mon, 5 Aug 2024 13:18:00 -0400
Message-ID: <CAN+1HbpB28NpJK3EQzyCzupufP5KjQCCOoRUVuHBFQZQWWyRPQ@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000009e42ba061ef2dc93"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--0000000000009e42ba061ef2dc93
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This appears to be intentional behavior of project's caching implemented
via (vc-file-getprop dir 'project-vc) and
(vc-file-setprop dir 'project-vc project) in project-try-vc. There is no
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.

Hope that helps,

-Stephane

On Sun, Aug 4, 2024 at 4:16=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote:

> > Date: Thu, 25 Jul 2024 21:54:24 +0200
> > From:  Federico Tedin via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> >
> > In Emacs master e56e4b345a2, `emacs -q`:
> >
> > I'm having problems trying to make project.el detect a new project that
> > is contained in the directory of another project.
> >
> > I have a directory called 'scratch' which contains a '.git' directory, =
a
> > file 'test.py' and a directory 'foo'. The 'foo' directory contains a
> > file called 'foo.py'.
> >
> >
> > ~/scratch/
> >     .git/
> >     main.py
> >     foo/
> >         foo.py
> >
> >
> > If I open 'main.py', `(project-current)' evals to the expected: `(vc Gi=
t
> > "~/scratch")'.
> >
> > If I open 'foo.py', `(project-current)' also evals to `(vc Git
> > "~/scratch")', which is expected.
> >
> > However if now I cd into 'foo/' and run `git init`, then I would expect
> > project.el to now consider 'foo.py' to be in another project - `(vc Git
> > "~/scratch/foo")'. However, if I evaluate `(project-current)' when
> > visiting 'foo.py', I still get `(vc Git "~/scratch")'.
> >
> > If I kill the buffer visiting 'foo.py' and open the file again, I get
> > the same result.
> >
> > Interestingly, if I run 'M-x project-remember-projects-under' with
> > '~/scratch/foo' as path, it does inform me that the new project has bee=
n
> > found. However visiting 'foo.py` still results in `(vc Git "~/scratch")=
'
> > as the current project.
> >
> > If I restart Emacs then the problem is solved; 'foo.py' is correctly
> > filed under project `(vc Git "~/scratch/foo")'.
> >
> > The fact that this works correctly after restarting makes me think
> > that there must be some runtime state set up that is preventing the
> > desired behaviour to happen.
>
> Dmitry, any comments or suggestions?
>
>
>
>

--0000000000009e42ba061ef2dc93
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D""><=
font face=3D"monospace">This appears to be intentional behavior of project&=
#39;s caching implemented via=C2=A0(vc-file-getprop dir &#39;project-vc) an=
d</font></div><div class=3D"gmail_default" style=3D""><font face=3D"monospa=
ce">(vc-file-setprop dir &#39;project-vc project) in=C2=A0project-try-vc. T=
here is no facility, public API or private, to clear the cache en-masse. On=
e could 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&#39;s in your=C2=A0</font><span style=3D"font-family=
:monospace">vc-file-prop-obarray for yourself before taking this action.</s=
pan></div><div class=3D"gmail_default" style=3D""><font face=3D"monospace">=
<br></font></div><div class=3D"gmail_default" style=3D""><font face=3D"mono=
space">Hope that helps,</font></div><div class=3D"gmail_default" style=3D""=
><font face=3D"monospace"><br></font></div><div class=3D"gmail_default" sty=
le=3D""><font face=3D"monospace">-Stephane</font></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Aug 4, 2024 =
at 4:16=E2=80=AFAM Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN">eliz@g=
nu.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">&gt; Date: Thu, 25 Jul 2024 21:54:24 +0200<br>
&gt; From:=C2=A0 Federico Tedin via &quot;Bug reports for GNU Emacs,<br>
&gt;=C2=A0 the Swiss army knife of text editors&quot; &lt;<a href=3D"mailto=
:bug-gnu-emacs@HIDDEN" target=3D"_blank">bug-gnu-emacs@HIDDEN</a>&gt;<br>
&gt; <br>
&gt; In Emacs master e56e4b345a2, `emacs -q`:<br>
&gt; <br>
&gt; I&#39;m having problems trying to make project.el detect a new project=
 that<br>
&gt; is contained in the directory of another project.<br>
&gt; <br>
&gt; I have a directory called &#39;scratch&#39; which contains a &#39;.git=
&#39; directory, a<br>
&gt; file &#39;test.py&#39; and a directory &#39;foo&#39;. The &#39;foo&#39=
; directory contains a<br>
&gt; file called &#39;foo.py&#39;.<br>
&gt; <br>
&gt; <br>
&gt; ~/scratch/<br>
&gt;=C2=A0 =C2=A0 =C2=A0.git/<br>
&gt;=C2=A0 =C2=A0 =C2=A0main.py<br>
&gt;=C2=A0 =C2=A0 =C2=A0foo/<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0foo.py<br>
&gt; <br>
&gt; <br>
&gt; If I open &#39;main.py&#39;, `(project-current)&#39; evals to the expe=
cted: `(vc Git<br>
&gt; &quot;~/scratch&quot;)&#39;.<br>
&gt; <br>
&gt; If I open &#39;foo.py&#39;, `(project-current)&#39; also evals to `(vc=
 Git<br>
&gt; &quot;~/scratch&quot;)&#39;, which is expected.<br>
&gt; <br>
&gt; However if now I cd into &#39;foo/&#39; and run `git init`, then I wou=
ld expect<br>
&gt; project.el to now consider &#39;foo.py&#39; to be in another project -=
 `(vc Git<br>
&gt; &quot;~/scratch/foo&quot;)&#39;. However, if I evaluate `(project-curr=
ent)&#39; when<br>
&gt; visiting &#39;foo.py&#39;, I still get `(vc Git &quot;~/scratch&quot;)=
&#39;.<br>
&gt; <br>
&gt; If I kill the buffer visiting &#39;foo.py&#39; and open the file again=
, I get<br>
&gt; the same result.<br>
&gt; <br>
&gt; Interestingly, if I run &#39;M-x project-remember-projects-under&#39; =
with<br>
&gt; &#39;~/scratch/foo&#39; as path, it does inform me that the new projec=
t has been<br>
&gt; found. However visiting &#39;foo.py` still results in `(vc Git &quot;~=
/scratch&quot;)&#39;<br>
&gt; as the current project.<br>
&gt; <br>
&gt; If I restart Emacs then the problem is solved; &#39;foo.py&#39; is cor=
rectly<br>
&gt; filed under project `(vc Git &quot;~/scratch/foo&quot;)&#39;.<br>
&gt; <br>
&gt; The fact that this works correctly after restarting makes me think<br>
&gt; that there must be some runtime state set up that is preventing the<br=
>
&gt; desired behaviour to happen.<br>
<br>
Dmitry, any comments or suggestions?<br>
<br>
<br>
<br>
</blockquote></div></div>

--0000000000009e42ba061ef2dc93--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72300: project.el: detect newly created project contained within another
Resent-From: Federico Tedin <federicotedin@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 05 Aug 2024 19:57:02 +0000
Resent-Message-ID: <handler.72300.B72300.172288781810056 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72300
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ship Mints <shipmints@HIDDEN>
Cc: Dmitry Gutov <dmitry@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 72300 <at> debbugs.gnu.org
Received: via spool by 72300-submit <at> debbugs.gnu.org id=B72300.172288781810056
          (code B ref 72300); Mon, 05 Aug 2024 19:57:02 +0000
Received: (at 72300) by debbugs.gnu.org; 5 Aug 2024 19:56:58 +0000
Received: from localhost ([127.0.0.1]:59506 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sb3pC-0002c5-HL
	for submit <at> debbugs.gnu.org; Mon, 05 Aug 2024 15:56:58 -0400
Received: from mout.gmx.net ([212.227.15.18]:43763)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <federicotedin@HIDDEN>) id 1sb3pA-0002bj-Ab
 for 72300 <at> debbugs.gnu.org; Mon, 05 Aug 2024 15:56:57 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de;
 s=s31663417; t=1722887783; x=1723492583; i=federicotedin@HIDDEN;
 bh=Rd5O6dPdst4e4Acp7CV/43ID8f8xn3k5b8UTReywpXg=;
 h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date:
 Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding:
 content-type:date:from:message-id:mime-version:reply-to:subject:
 to;
 b=hcNwXa39sLPn0bdM/fOGtRDADsWnUv1MNRxKq8x3brZjrRv6vNicfviaI78PdgLv
 QmTWz+celkhT6lQGJB2ao6D72K1ZdnSA1k6GCaGh/rul3f1x0XbWHWA/Qrd7fvUcb
 qyAKbUNshkdGGwrnF1/v73iVwapGAO3sYZWMy2Uo51IWfvpdJhlYKhOdV/Nf3sVjU
 K95UTVRKbI/+8AXVB0jhmRZjS930ewqEThkxFF0IMDjvajtFbNMrfFS6+tBIhEUf8
 pN7SMcVkt8v8koop7X5NHK8ptRzc/lNAx6/rFpTTJRMwGcr7h+r5Yh9Soik+7zJNX
 ldS/6xiu5yvnC9ByVw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from seele ([91.66.5.21]) by mail.gmx.net (mrgmx004
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MgNh7-1s1BAe1gjP-00mT5L; Mon, 05
 Aug 2024 21:56:23 +0200
From: Federico Tedin <federicotedin@HIDDEN>
In-Reply-To: <CAN+1HbpB28NpJK3EQzyCzupufP5KjQCCOoRUVuHBFQZQWWyRPQ@HIDDEN>
 (Ship Mints's message of "Mon, 5 Aug 2024 13:18:00 -0400")
References: <87r0bh8cy7.fsf@HIDDEN> <86mslssny9.fsf@HIDDEN>
 <CAN+1HbpB28NpJK3EQzyCzupufP5KjQCCOoRUVuHBFQZQWWyRPQ@HIDDEN>
Date: Mon, 05 Aug 2024 21:56:15 +0200
Message-ID: <87a5hqyc9s.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:1fevFXK1vI6mgIYG7qaH+VE8IyWtYZMUFIfjkCoe3Y/1vL9/waJ
 72TN5+U/SnGlG9gcJD6H7fmiKOjPa+w4XZ5uLQbEGjleaTt7IxJI0Y7Y0EB5Sj9rk2P3i4m
 4lEgKsWAYBfV2YOfR17Qds+0zaOH2AseDn1aH47M+PKrkat/ryfK3KWAuMztnijVofDG193
 dvTSIit2eLEZn/lkn/8rQ==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:Pqe1hK/m7pw=;aPlktrgvdAVJ8QjITBONgtvSQtd
 qNHpxVeL6J/Fu2K1ymeESAfp8n2D8a65JCxHSJd60WbhZHoa/2RV082x2xtPblZTj79wFLGCv
 XS3ggc2+vR9ZpLZZvqO+YFKIPqyuZI6vTalUsOS5dvi5aARBkcUcTCp7t5SnJcapM/B555CHW
 bf/gS4aSWuIxUVlv3P9clgEEgXe1PNoDFLJtOjHPsKG9lhT6/ndHp8aODhR5N1pyw9Z6EQK+0
 OF2d/pRA7TgDT1nK96h7gtt9SJtZtIeV0LVPzBuec6/MLwEihRwZ+JfgoYevv8R7fWOrAEofl
 99RMpVNmY74foFBVyp7xeemXq+6DaSisSNgggULroixUB5nSJWd95PG2UVPyHiGtaJ43G8IXY
 I3NbHL+1cUov1fTNDvglLZg/uoLZrJ5HMK6xsUHo2n8AzHp35WYp2G2eblt31xdqZ2NiV5VlK
 0DyW1HNRvYKP64xQq155VmNyl/kjC/GofzmTjY5JvRVrjS6OjNgzVaWCaWlR7s51cbRP1pTVG
 UBtmRtgS6tAc2xnZaaoUmYUbj5WqkJo+IOE+CO5r5LdEhClEaBw5/Uznp3fnjThc5xm2y/TQy
 30+Xx8YqJFwqEkYmSP8R8ld8MyQj9zuEbKYIVCIir1TbNN3GhgMcXhFBo5YE6gqutOBPeQV7X
 L8gaTOr/lxKbfYdsR0Gehi0baA4nicfq78f7iij5Bw7YTPi5FLlso5Ep+TJIC2RUXgem0nOn7
 R9FVkFC0jAI75+UHZgmDDSGLa1v2w2yQKUiMj++rhj2VVhg4IeLJWDLM+8DqaxPaO0umHePMo
 vYqJeuLBbOme8oVs+Hf+1vpw==
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Ship Mints <shipmints@HIDDEN> writes:

> This appears to be intentional behavior of project's caching implemented via (vc-file-getprop dir 'project-vc) and
> (vc-file-setprop dir 'project-vc project) in project-try-vc. There is no 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.

Ah wow, indeed setting that variable to (make-vector 17 0) does solve
the problem. Thanks! Now I wonder if this could/should be exposed to the
user somehow.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72300: project.el: detect newly created project contained within another
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 13 Aug 2024 01:44:02 +0000
Resent-Message-ID: <handler.72300.B72300.172351343116256 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72300
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ship Mints <shipmints@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Cc: 72300 <at> debbugs.gnu.org, Federico Tedin <federicotedin@HIDDEN>
Received: via spool by 72300-submit <at> debbugs.gnu.org id=B72300.172351343116256
          (code B ref 72300); Tue, 13 Aug 2024 01:44:02 +0000
Received: (at 72300) by debbugs.gnu.org; 13 Aug 2024 01:43:51 +0000
Received: from localhost ([127.0.0.1]:43961 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sdgZj-0004E5-6R
	for submit <at> debbugs.gnu.org; Mon, 12 Aug 2024 21:43:51 -0400
Received: from fhigh1-smtp.messagingengine.com ([103.168.172.152]:44041)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1sdgZg-0004Do-WB
 for 72300 <at> debbugs.gnu.org; Mon, 12 Aug 2024 21:43:50 -0400
Received: from phl-compute-03.internal (phl-compute-03.nyi.internal
 [10.202.2.43])
 by mailfhigh.nyi.internal (Postfix) with ESMTP id 130AB1151A2B;
 Mon, 12 Aug 2024 21:43:11 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-03.internal (MEProxy); Mon, 12 Aug 2024 21:43:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
 :cc:content-transfer-encoding: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=fm2; t=1723513391;
 x=1723599791; bh=UbKDsQBq9zeIxf7l5afcZUnLUeTamLt5MlQLLV8qe6E=; b=
 ubZh4dvQ9ofLzkKAEwgtu1A/XigN/dtuVCsEsChGqo7YzdrD8QrclxxxHk+pyidp
 SP6Lh6wWBfkuvqTk8MOVpSARtjptQw635tKt2lQ59k95zIJ5CA3OTx61oUYpw2HW
 +Tec1XsudJxhqi8/QMG2B97LoDU17KYc0bMBBMC2qkCb32twUbr+LYbdnotMMCIZ
 KooJmf6c8pfLMcGT6yRZxQkpIAMJ1IMyzPzzNyuXWAXXB+HriEMVV/5SkSItvxk1
 NGE+5eo2xjmWUlKyEjOacUbb3YuX4uDFTzJVLSf0fpFwLAzpIltlfhI18XIg0IKV
 yJLmhPRumkPpd9L4aGOkBQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :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=fm3; t=1723513391; x=
 1723599791; bh=UbKDsQBq9zeIxf7l5afcZUnLUeTamLt5MlQLLV8qe6E=; b=s
 lf9my4Arfo5FPcin7TMscwXbURrGrPgcAK7G5K68PKDPCRvh70tBiSYSQpq8k6lf
 e8BKiQr45BraW1v2kh+T+mnQygnfZiYc3cPTrmHQGu1Cb6MKJbFh2p9lnoq1Xzn0
 r4rLhPso5njNGiyMAxlvVkUb6elicZ9+W60+H7Xh0QKQvMvBloef9Tji76dhKQfs
 z5sjBRNDRAi78WTejrdIn8ma8zgCdZTi8ozkre79nkzXT8DtFMOJ+AjQJ1rbKJuy
 lGLTRertnnIFTtAm5UpirKrHJfhiLU3MVM0LhxZ01VGOxJx7lbjAWEpT9sl1tBLS
 cRQgQPdo6zE2VlW07QFBw==
X-ME-Sender: <xms:Lrq6Zr_IYDVRoxGIoTcprEY4Fh53DaVAfIYQ2-sBsrduMOXU_HgPOA>
 <xme:Lrq6Znsvm6j_1frRUyhAZC622r6ER6WkguVKmLjdUNJCdFupkJujBcdFGxZLH17Tp
 wbyjCPRxcuARJx9JcQ>
X-ME-Received: <xmr:Lrq6ZpARgJ1y8aDVR3_IPQnp3mh2d7ewYQcq3LSsBWVJcS_m6O3A77hN-RH1ZpHYbSU>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddtuddgheduucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdej
 necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug
 gvvheqnecuggftrfgrthhtvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveeg
 tedthefhudekteehffeukeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe
 hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho
 peegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehshhhiphhmihhnthhssehgmh
 grihhlrdgtohhmpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohep
 fhgvuggvrhhitghothgvughinhesghhmgidruggvpdhrtghpthhtohepjedvfedttdesug
 gvsggsuhhgshdrghhnuhdrohhrgh
X-ME-Proxy: <xmx:Lrq6ZndG8nS1bRY1WJvGbrDD4wU23lOJebjeRInxLqIWfG5UyQAQMQ>
 <xmx:Lrq6ZgOvbtqFnI1MtYZUFAx6EdWUg3zTY8aQXl45NA1uemOGwnm8VQ>
 <xmx:Lrq6ZpnSB-RM8QD2EDXydqFxoSV2qVB1LNxcttXa_Fky3Bqml6rnZA>
 <xmx:Lrq6ZquyM2QKSs3PwLvsIWhxOKBf84JWcDlTVzj_Y_yVVwTMdM-lng>
 <xmx:L7q6ZtrLSmOM91l56ZVYidg5XbjXfUCuvFVs1nMH3ijLIRCGip2QWTi6>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 12 Aug 2024 21:43:09 -0400 (EDT)
Message-ID: <04986428-27b5-462d-8f89-139cd56ea117@HIDDEN>
Date: Tue, 13 Aug 2024 04:43:06 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <87r0bh8cy7.fsf@HIDDEN> <86mslssny9.fsf@HIDDEN>
 <CAN+1HbpB28NpJK3EQzyCzupufP5KjQCCOoRUVuHBFQZQWWyRPQ@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <CAN+1HbpB28NpJK3EQzyCzupufP5KjQCCOoRUVuHBFQZQWWyRPQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Hi!

On 05/08/2024 20:18, Ship Mints wrote:
> (vc-file-setprop dir 'project-vc project) in project-try-vc. There is no 
> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72300: project.el: detect newly created project contained within another
Resent-From: Ship Mints <shipmints@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 13 Aug 2024 13:33:02 +0000
Resent-Message-ID: <handler.72300.B72300.172355597631465 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72300
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: 72300 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Federico Tedin <federicotedin@HIDDEN>
Received: via spool by 72300-submit <at> debbugs.gnu.org id=B72300.172355597631465
          (code B ref 72300); Tue, 13 Aug 2024 13:33:02 +0000
Received: (at 72300) by debbugs.gnu.org; 13 Aug 2024 13:32:56 +0000
Received: from localhost ([127.0.0.1]:44611 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sdrdv-0008BO-66
	for submit <at> debbugs.gnu.org; Tue, 13 Aug 2024 09:32:56 -0400
Received: from mail-vk1-f173.google.com ([209.85.221.173]:58616)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <shipmints@HIDDEN>) id 1sdrds-0008B7-Ug
 for 72300 <at> debbugs.gnu.org; Tue, 13 Aug 2024 09:32:53 -0400
Received: by mail-vk1-f173.google.com with SMTP id
 71dfb90a1353d-4f6ba99286cso1729729e0c.0
 for <72300 <at> 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)
MIME-Version: 1.0
References: <87r0bh8cy7.fsf@HIDDEN> <86mslssny9.fsf@HIDDEN>
 <CAN+1HbpB28NpJK3EQzyCzupufP5KjQCCOoRUVuHBFQZQWWyRPQ@HIDDEN>
 <04986428-27b5-462d-8f89-139cd56ea117@HIDDEN>
In-Reply-To: <04986428-27b5-462d-8f89-139cd56ea117@HIDDEN>
From: Ship Mints <shipmints@HIDDEN>
Date: Tue, 13 Aug 2024 09:31:02 -0400
Message-ID: <CAN+1HbovL9SFG9Pj1gVJg4Xv+yxEA8ciX3LvafNpn25C_k+Cfg@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000098b72c061f909f83"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--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 <dmitry@HIDDEN> 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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e">A good step is awareness for users and invalidating the cache via projec=
t-forget methods is a good idea. I&#39;d also offer a direct function to in=
voke to invalidate the cache for programmatic use.</div><div class=3D"gmail=
_default" style=3D"font-family:monospace"><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:monospace">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 &quot;mono repo&quot; 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.</div><div class=3D"gma=
il_default" style=3D"font-family:monospace"><br></div><div class=3D"gmail_d=
efault" style=3D"font-family:monospace">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&#39;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&#39;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?</div><div class=3D"gmail_def=
ault" style=3D"font-family:monospace"><br></div><div class=3D"gmail_default=
" style=3D"font-family:monospace">-Stephane</div></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 12, 2024 at 9:=
43=E2=80=AFPM Dmitry Gutov &lt;<a href=3D"mailto:dmitry@HIDDEN">dmitry@g=
utov.dev</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">Hi!<br>
<br>
On 05/08/2024 20:18, Ship Mints wrote:<br>
&gt; (vc-file-setprop dir &#39;project-vc project) in=C2=A0project-try-vc. =
There is no <br>
&gt; facility, public API or private, to clear the cache en-masse. One coul=
d <br>
&gt; reset the cache via clearing the vector=C2=A0vc-file-prop-obarray <br>
&gt; (setq=C2=A0vc-file-prop-obarray (make-vector 17 0)) in the absence of =
an API. <br>
&gt; You can observe what&#39;s in your vc-file-prop-obarray for yourself b=
efore <br>
&gt; taking this action.<br>
<br>
That&#39;s right. One step toward that goal would be moving the cache to <b=
r>
some other data structure - possibly a tree-like one, to also be able to <b=
r>
short-circuit the upward directory searches.<br>
<br>
Cache invalidation is a sore point, though: the directory tree can <br>
change behind the scenes outside Emacs, so unless the caching is <br>
disabled the other complete solutions would rely on something like <br>
filenotify.<br>
<br>
OT2H if we&#39;re okay with supporting only manual clears e.g. using &#39;M=
-x <br>
project-forget-project&#39; or &#39;M-x project-forget-projects-under&#39;,=
 that <br>
could be implemented easily enough. The current vc-file-prop-obarray <br>
structure could be refreshed with a full scan.<br>
</blockquote></div>

--00000000000098b72c061f909f83--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72300: project.el: detect newly created project contained within another
Resent-From: Ship Mints <shipmints@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 13 Aug 2024 14:53:01 +0000
Resent-Message-ID: <handler.72300.B72300.17235607289408 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72300
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: 72300 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Federico Tedin <federicotedin@HIDDEN>
Received: via spool by 72300-submit <at> debbugs.gnu.org id=B72300.17235607289408
          (code B ref 72300); Tue, 13 Aug 2024 14:53:01 +0000
Received: (at 72300) by debbugs.gnu.org; 13 Aug 2024 14:52:08 +0000
Received: from localhost ([127.0.0.1]:45361 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sdssZ-0002Rd-QL
	for submit <at> debbugs.gnu.org; Tue, 13 Aug 2024 10:52:08 -0400
Received: from mail-ua1-f47.google.com ([209.85.222.47]:42172)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <shipmints@HIDDEN>) id 1sdssW-0002R2-My
 for 72300 <at> debbugs.gnu.org; Tue, 13 Aug 2024 10:52:06 -0400
Received: by mail-ua1-f47.google.com with SMTP id
 a1e0cc1a2514c-82e2eee5f5cso3046741241.0
 for <72300 <at> debbugs.gnu.org>; Tue, 13 Aug 2024 07:51:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1723560625; x=1724165425; 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=H2jWaPRv5oWIMCeWSq5t1V/filSTsw6oAq11kRk//AE=;
 b=BL/GB0lYTbH59TH7CoKwtF8l4DBG9V2qZj0428dqkKZvZ90bzZ7++ONNMPj6vFxN5j
 YLdEDDAVcp71RA+sg9QQAGL8kaiCSE6HIeUPjLOwJTBRBOVxA+VRL7GT0NeZE9Ni+1DJ
 jRbpinV/OT3jO8Db0Vmy2Ht95kqV8whjRGeGRJneTS8SdBh2FKzxuV81MoH7UkDVUHgn
 gSUs1Td61QQYB0mR/jfkn/GL8a8gm0/pbkWVkVUqQ4SjpXDhNklo7eQg5A04RoCmWfQs
 jBX0suQmOsplk4+6OFlAflPJvEN4JYARQt4Z92q0yEgWFV6wWVVazMz7szrD5PEivvkY
 QyWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1723560625; x=1724165425;
 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=H2jWaPRv5oWIMCeWSq5t1V/filSTsw6oAq11kRk//AE=;
 b=DIpH/puJ7xNm6txQ4ZYVFYjY4UAQ6Wa2v1QEcjM+uAM1tsRn8RKUqfnd4AqvX4qLNh
 1S/fik4ZAs+ij+IR40cxT0z0fCPYTjgVUOLE3ldxkV2FcPVNVICWFHivaoKlLeScPUkJ
 E/mWxPgqGUzmAyGdrEIQrDS//Cq/kJ2OhotoDPxm5vVpsHQaE0AOlbGax2e22UFC9CG8
 Fkd4FD+9Tnwk9bcXyRwU+epAcqpdmWnjAmXxMCnTYpFE6VTGgUOaJ8T+6z5IXsX3RVfE
 ciUbz/Gbncp+fyVu3FYNQpokmFLziDauEPhEq/fHgVFiuCbpIyDC/ckHIWgvsfwt90+y
 eE5Q==
X-Forwarded-Encrypted: i=1;
 AJvYcCX1N3/TcxP192wDAUyhyGw68tqxGoIqnAXznE4VcUvNWyCLheke3XVTzMWqulcbNiLjgdieS5/kKyPsDkmeh9fkA9tciNg=
X-Gm-Message-State: AOJu0Yy7yf5Mu46MmFyL23p17Q3hx6H055E0wjFnqbkIzcAcbGltnd0J
 2gDq0yVZyKz5YfViwTWn0ra+tC0QhL3l+xLIVPD/PGHRqEKH5MZLH94PKbzLV0iMpZnvgUFkpyu
 6JSAet44NzlPi5t39cWMpr1LVmJY=
X-Google-Smtp-Source: AGHT+IFbndLzKxfGWUJTa1Del09h0UsMcvhRfZIc9jZwvdPt3E6XUvzBnry9uIpMJImv/pesHAGETZm0VGGG+EQKwHU=
X-Received: by 2002:a05:6102:3050:b0:493:b3b5:cc29 with SMTP id
 ada2fe7eead31-49746e23237mr1712439137.12.1723560624934; Tue, 13 Aug 2024
 07:50:24 -0700 (PDT)
MIME-Version: 1.0
References: <87r0bh8cy7.fsf@HIDDEN> <86mslssny9.fsf@HIDDEN>
 <CAN+1HbpB28NpJK3EQzyCzupufP5KjQCCOoRUVuHBFQZQWWyRPQ@HIDDEN>
 <04986428-27b5-462d-8f89-139cd56ea117@HIDDEN>
 <CAN+1HbovL9SFG9Pj1gVJg4Xv+yxEA8ciX3LvafNpn25C_k+Cfg@HIDDEN>
In-Reply-To: <CAN+1HbovL9SFG9Pj1gVJg4Xv+yxEA8ciX3LvafNpn25C_k+Cfg@HIDDEN>
From: Ship Mints <shipmints@HIDDEN>
Date: Tue, 13 Aug 2024 10:50:13 -0400
Message-ID: <CAN+1HbpLhn6O9C1QnYQ2_oPExGAuQQsEvOhEayTArv0f2FStjg@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000cc580b061f91bae2"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000cc580b061f91bae2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As some food for thought, we've used git attributes via "git check-attr" to
record custom metadata at the repository level to provide hints to tooling.
As project.el and other tools evolve, perhaps we can consider the cases
where users can supply functions that influence behavior where one use case
is based on things like git attributes. The case in hand is whether a
submodule should be considered external to a project.el project such as the
vendor/third-party submodule I'd mentioned. We use the
default project-vc-merge-submodules t and our exceptions could be encoded
via a custom git attribute and indicated via a predicate function, perhaps.
In the absence of formal guidelines, and git does not seem to define
"reserved words" for naming, we prefix custom attributes with an underscore=
.

On Tue, Aug 13, 2024 at 9:31=E2=80=AFAM Ship Mints <shipmints@HIDDEN> wr=
ote:

> 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 t=
o
> invoke to invalidate the cache for programmatic use.
>
> vc caching, longer term, may need to consider a few more complex use case=
s
> 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 wi=
th
> web and mobile front end code in submodules that are treated as part of t=
he
> 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 f=
or
> 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 user=
s?
>
> -Stephane
>
> On Mon, Aug 12, 2024 at 9:43=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> w=
rote:
>
>> Hi!
>>
>> On 05/08/2024 20:18, Ship Mints wrote:
>> > (vc-file-setprop dir 'project-vc project) in project-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 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 befor=
e
>> > 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.
>>
>

--000000000000cc580b061f91bae2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e">As some food for thought, we&#39;ve used git attributes via &quot;git ch=
eck-attr&quot; to record custom metadata=C2=A0at the repository level to pr=
ovide hints to tooling. As project.el and other tools evolve, perhaps we ca=
n consider the cases where users can supply functions that influence behavi=
or where one use case is based on things like git attributes. The case in h=
and is whether a submodule should be considered external to a project.el pr=
oject such as the vendor/third-party submodule I&#39;d mentioned. We use th=
e default=C2=A0project-vc-merge-submodules t and our exceptions could be en=
coded via a custom git attribute and indicated via a predicate function,=C2=
=A0perhaps. In the absence of formal guidelines, and git does not seem to d=
efine &quot;reserved words&quot; for naming, we prefix custom attributes wi=
th an underscore.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Tue, Aug 13, 2024 at 9:31=E2=80=AFAM Ship Mints &=
lt;<a href=3D"mailto:shipmints@HIDDEN">shipmints@HIDDEN</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_default" style=3D"font-family:monospace">A good step=
 is awareness for users and invalidating the cache via project-forget metho=
ds is a good idea. I&#39;d also offer a direct function to invoke to invali=
date the cache for programmatic use.</div><div class=3D"gmail_default" styl=
e=3D"font-family:monospace"><br></div><div class=3D"gmail_default" style=3D=
"font-family:monospace">vc caching, longer term, may need to consider a few=
 more complex use cases such as git repos with both submodules that are con=
sidered extensions of the base project and submodules which are not. A conc=
rete example I see often is a &quot;mono repo&quot; structure with core ser=
ver and library code but with web and mobile front end code in submodules t=
hat are treated as part of the project proper BUT with submodules for vendo=
r/third-party code that are not. A question here would be which parts of th=
e tree belong to which cached vc root.</div><div class=3D"gmail_default" st=
yle=3D"font-family:monospace"><br></div><div class=3D"gmail_default" style=
=3D"font-family:monospace">Another=C2=A0use case I see is working on many u=
nrelated projects/repos across a variety of clients all in the same Emacs s=
ession and with perhaps 100+ buffers/files open (as I pretty much have righ=
t now), a 17-element cache won&#39;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=C2=A0share the same repo ro=
ot and some that don&#39;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 migh=
t be more natural to Emacs users?</div><div class=3D"gmail_default" style=
=3D"font-family:monospace"><br></div><div class=3D"gmail_default" style=3D"=
font-family:monospace">-Stephane</div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 12, 2024 at 9:43=E2=80=AF=
PM Dmitry Gutov &lt;<a href=3D"mailto:dmitry@HIDDEN" target=3D"_blank">d=
mitry@HIDDEN</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">Hi!<br>
<br>
On 05/08/2024 20:18, Ship Mints wrote:<br>
&gt; (vc-file-setprop dir &#39;project-vc project) in=C2=A0project-try-vc. =
There is no <br>
&gt; facility, public API or private, to clear the cache en-masse. One coul=
d <br>
&gt; reset the cache via clearing the vector=C2=A0vc-file-prop-obarray <br>
&gt; (setq=C2=A0vc-file-prop-obarray (make-vector 17 0)) in the absence of =
an API. <br>
&gt; You can observe what&#39;s in your vc-file-prop-obarray for yourself b=
efore <br>
&gt; taking this action.<br>
<br>
That&#39;s right. One step toward that goal would be moving the cache to <b=
r>
some other data structure - possibly a tree-like one, to also be able to <b=
r>
short-circuit the upward directory searches.<br>
<br>
Cache invalidation is a sore point, though: the directory tree can <br>
change behind the scenes outside Emacs, so unless the caching is <br>
disabled the other complete solutions would rely on something like <br>
filenotify.<br>
<br>
OT2H if we&#39;re okay with supporting only manual clears e.g. using &#39;M=
-x <br>
project-forget-project&#39; or &#39;M-x project-forget-projects-under&#39;,=
 that <br>
could be implemented easily enough. The current vc-file-prop-obarray <br>
structure could be refreshed with a full scan.<br>
</blockquote></div>
</blockquote></div>

--000000000000cc580b061f91bae2--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72300: project.el: detect newly created project contained within another
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 30 Sep 2024 01:36:03 +0000
Resent-Message-ID: <handler.72300.B72300.172766015529804 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72300
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ship Mints <shipmints@HIDDEN>
Cc: 72300 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Federico Tedin <federicotedin@HIDDEN>
Received: via spool by 72300-submit <at> debbugs.gnu.org id=B72300.172766015529804
          (code B ref 72300); Mon, 30 Sep 2024 01:36:03 +0000
Received: (at 72300) by debbugs.gnu.org; 30 Sep 2024 01:35:55 +0000
Received: from localhost ([127.0.0.1]:43445 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sv5KK-0007k6-7p
	for submit <at> debbugs.gnu.org; Sun, 29 Sep 2024 21:35:55 -0400
Received: from fhigh-a4-smtp.messagingengine.com ([103.168.172.155]:60147)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1sv5KI-0007jK-2K
 for 72300 <at> debbugs.gnu.org; Sun, 29 Sep 2024 21:35:51 -0400
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)
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: <xms:TwD6ZijA1EJV8WMqutplgP3xUWD1rW25lqsAIh1GuwPTK50QxmKkvg>
 <xme:TwD6ZjDdD7YmqJl_-ZNTHOWPnJUcszCQqsFRagJn52cbgqStTx6oSEJIx_WDfCnx5
 4JqLtmjoJMDarlSCW0>
X-ME-Received: <xmr:TwD6ZqGlGkUYtT-mcwxmXpJLCHA55e_8MZg0u2ArAIEu5jQBdyLYYBpMEYb2vB2CFMo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddugedggeekucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurheptgfkffggfgfuvfevfhfhjgesmhdtreertddvjeen
 ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg
 hvqeenucggtffrrghtthgvrhhnpeehleefudekudduveekieelgfeiffdvkefhkeeljeeu
 jeegueekveffkeejjeevheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh
 grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep
 gedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepshhhihhpmhhinhhtshesghhmrg
 hilhdrtghomhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehf
 vgguvghrihgtohhtvgguihhnsehgmhigrdguvgdprhgtphhtthhopeejvdeftddtseguvg
 gssghughhsrdhgnhhurdhorhhg
X-ME-Proxy: <xmx:TwD6ZrSXdvBhlhieMjXame2EWNFc41JBZ9B2gDlTnRYxRd1e3ciFNg>
 <xmx:TwD6ZvwT_hygfSiCq3ebNyPdWPZj_rn_GBaHq23Wo_CtBr4vC_SgLQ>
 <xmx:TwD6Zp6GWRMlfSN_jge4gySELobxzIKG2-ejD94x1O9LA1fqRTV6rg>
 <xmx:TwD6ZszWVTxU6gqEhvh2soKiNRUaa8VlzL4oN6kj0PU7GsQmpVH83g>
 <xmx:UAD6Zhvz5itOAX_J6ZDsNxT20rhckRXlZzg3uYkpVcvn_aQ6B1h7z-cL>
Feedback-ID: i07de48aa:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 29 Sep 2024 21:35:09 -0400 (EDT)
Content-Type: multipart/mixed; boundary="------------s053ZgMouh4gMNsVviLVZNP9"
Message-ID: <1acc2892-24fe-41fd-802c-8c9ba78eddbd@HIDDEN>
Date: Mon, 30 Sep 2024 04:35:07 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <87r0bh8cy7.fsf@HIDDEN> <86mslssny9.fsf@HIDDEN>
 <CAN+1HbpB28NpJK3EQzyCzupufP5KjQCCOoRUVuHBFQZQWWyRPQ@HIDDEN>
 <04986428-27b5-462d-8f89-139cd56ea117@HIDDEN>
 <CAN+1HbovL9SFG9Pj1gVJg4Xv+yxEA8ciX3LvafNpn25C_k+Cfg@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <CAN+1HbovL9SFG9Pj1gVJg4Xv+yxEA8ciX3LvafNpn25C_k+Cfg@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

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--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72300: project.el: detect newly created project contained within another
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 30 Sep 2024 01:53:02 +0000
Resent-Message-ID: <handler.72300.B72300.17276611506356 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72300
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ship Mints <shipmints@HIDDEN>
Cc: 72300 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Federico Tedin <federicotedin@HIDDEN>
Received: via spool by 72300-submit <at> debbugs.gnu.org id=B72300.17276611506356
          (code B ref 72300); Mon, 30 Sep 2024 01:53:02 +0000
Received: (at 72300) by debbugs.gnu.org; 30 Sep 2024 01:52:30 +0000
Received: from localhost ([127.0.0.1]:43605 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sv5aG-0001di-Ho
	for submit <at> debbugs.gnu.org; Sun, 29 Sep 2024 21:52:30 -0400
Received: from fhigh-a4-smtp.messagingengine.com ([103.168.172.155]:55033)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1sv5ZT-0001XB-Sq
 for 72300 <at> debbugs.gnu.org; Sun, 29 Sep 2024 21:52:18 -0400
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfhigh.phl.internal (Postfix) with ESMTP id EB70D1140172;
 Sun, 29 Sep 2024 21:50:42 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Sun, 29 Sep 2024 21:50:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
 :cc:content-transfer-encoding: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=1727661042;
 x=1727747442; bh=w1ffj0OKI0mggx6Rxv1JkhAjDvpH6apv9m7xR2A4t/U=; b=
 c6qnae5/SAx+WTSW7MU+TSscVg+xH4AXGREnuLepyYNmsRLGz3XupmrlVAJD9J4y
 RQVqT9JTCMHuJ/utTnrntYMdYkW8lDWHmBhSYBOEDnz0Ma+cYzSsMFERhMi5EriO
 9zpaPS3nCDX7W6SK0ueKNBAoUmA4BKnBiCOdG3WD+GFYWroriwnTMNEi8nsxUIyU
 RzzO23BGvAn3yv8/O6Y3n/QF4/+P93SuyTQdwhkJMAbg191HFPjVaz/Aq5jkUykU
 qD5GhdU9bXG+TaI0LWN2/wFtX6ejht1eKCQW0RJeBgeCsL42npZOoeNu8c78c6Bg
 xj5uxRglpf6WyUFAIgPRIQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :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=1727661042; x=
 1727747442; bh=w1ffj0OKI0mggx6Rxv1JkhAjDvpH6apv9m7xR2A4t/U=; b=N
 aSydS0gu6E3cUlsKITTgq5aA+eYdfcWeAXknbxFzwRoF43HoM+5Xkm2yLD3QAnBA
 vGxx42Bend5K+OMoRYrOGf/Y8J0kOT4VCswz1CtzN4fDYzsKOZgpMqrpMGhovIic
 4I1qRubl2xE4G4bsYsPKwRO3cowIM8bqOafrcf0qIZMrgAV6p8VA9JwkQ+J/xYB+
 znca93DppUE9PfRvomgL6Ci9Hc8Vm40xweLzOnJGSQpmj0OM/AX4x3j/TbBUCSxi
 KXApxHzzIWiR+R7ZNk6FZ+DnW4gO7qqIQjFo1AyC01RkgR0Ch2ZJTrYDJwo45vXg
 AI735loxr7rUanrdx2I9g==
X-ME-Sender: <xms:8gP6ZjTMSnjR6-TzUKtXAL2wD8U_lfrlETLrAeZBcLdez1pr5rNC3w>
 <xme:8gP6ZkzGNQvUcxT1mR0Uw5IdrpAIk6yNulVwn2Uf225L5Ho03wJzleTmuSzniityT
 y66vggO5nlhv46G5B0>
X-ME-Received: <xmr:8gP6Zo0OfsNJQZrmjNA-plsHRqXqorkcnBs9O-s3gS4Dx4YzoDrnjaA6tvZRpFpBEUo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddugedghedvucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdej
 necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug
 gvvheqnecuggftrfgrthhtvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveeg
 tedthefhudekteehffeukeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe
 hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho
 peegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehshhhiphhmihhnthhssehgmh
 grihhlrdgtohhmpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohep
 fhgvuggvrhhitghothgvughinhesghhmgidruggvpdhrtghpthhtohepjedvfedttdesug
 gvsggsuhhgshdrghhnuhdrohhrgh
X-ME-Proxy: <xmx:8gP6ZjBMnnLp-5mQ8ZWFC30fbAm-UYRkMiIA4RlG5rHesp-R0n-2kQ>
 <xmx:8gP6ZshUXR5EZ91TKIa8VfJWm2bBR3WxiN7--wXgvVyZKa6xnYFRpQ>
 <xmx:8gP6ZnplL-FIGoRHBzT4r882U5q5-_45A132zGXuWd8zZTszOXt3IQ>
 <xmx:8gP6Znhib0FHXXw4rM03fzaZWtxZ3TNdJ0lx7DJsbMJ3ToPFx4GvzA>
 <xmx:8gP6ZkfIzbXkQQdPv01Bbj6j0UxaLmVBjT0Lx2Sc2QE6GvfA_ghkKWTt>
Feedback-ID: i07de48aa:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 29 Sep 2024 21:50:40 -0400 (EDT)
Message-ID: <4ecab405-a03f-4dd7-af4b-f2d29b0420a4@HIDDEN>
Date: Mon, 30 Sep 2024 04:50:38 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <87r0bh8cy7.fsf@HIDDEN> <86mslssny9.fsf@HIDDEN>
 <CAN+1HbpB28NpJK3EQzyCzupufP5KjQCCOoRUVuHBFQZQWWyRPQ@HIDDEN>
 <04986428-27b5-462d-8f89-139cd56ea117@HIDDEN>
 <CAN+1HbovL9SFG9Pj1gVJg4Xv+yxEA8ciX3LvafNpn25C_k+Cfg@HIDDEN>
 <CAN+1HbpLhn6O9C1QnYQ2_oPExGAuQQsEvOhEayTArv0f2FStjg@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <CAN+1HbpLhn6O9C1QnYQ2_oPExGAuQQsEvOhEayTArv0f2FStjg@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On 13/08/2024 17:50, Ship Mints wrote:
> As some food for thought, we've used git attributes via "git check-attr" 
> to record custom metadata at the repository level to provide hints to 
> tooling. As project.el and other tools evolve, perhaps we can consider 
> the cases where users can supply functions that influence behavior where 
> one use case is based on things like git attributes. The case in hand is 
> whether a submodule should be considered external to a project.el 
> project such as the vendor/third-party submodule I'd mentioned. We use 
> the default project-vc-merge-submodules t and our exceptions could be 
> encoded via a custom git attribute and indicated via a predicate 
> function, perhaps. In the absence of formal guidelines, and git does not 
> seem to define "reserved words" for naming, we prefix custom attributes 
> with an underscore.

Git attributes is a possible approach, with a downside of extra process 
calls, which over Tramp (for example) would mean additional latency.

How about we just support filtering out submodules using the 
project-vc-ignores var? Which can be assigned in .dir-locals.el or 
through other means.

I kind of hoped this would work automatically, it does not, but adding 
the extra comparisons against the list of ignores seems natural enough.

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 599a350e5ce..79fcfb65f87 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -720,7 +731,9 @@ project--vc-list-files
           (let ((sub-files
                  (mapcar
                   (lambda (module)
-                   (when (file-directory-p module)
+                   (when (and (file-directory-p module)
+                              ;; TODO: Support real globs.
+                              (not (member module extra-ignores)))
                       (let ((sub-files
                              (project--vc-list-files
                               (concat default-directory module)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72300: project.el: detect newly created project contained within another
Resent-From: Ship Mints <shipmints@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 30 Sep 2024 14:46:03 +0000
Resent-Message-ID: <handler.72300.B72300.17277075275981 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72300
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: 72300 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Federico Tedin <federicotedin@HIDDEN>
Received: via spool by 72300-submit <at> debbugs.gnu.org id=B72300.17277075275981
          (code B ref 72300); Mon, 30 Sep 2024 14:46:03 +0000
Received: (at 72300) by debbugs.gnu.org; 30 Sep 2024 14:45:27 +0000
Received: from localhost ([127.0.0.1]:45261 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1svHeB-0001Vt-SO
	for submit <at> debbugs.gnu.org; Mon, 30 Sep 2024 10:45:25 -0400
Received: from mail-pl1-f172.google.com ([209.85.214.172]:54296)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <shipmints@HIDDEN>) id 1svHb3-0000Lc-5F
 for 72300 <at> debbugs.gnu.org; Mon, 30 Sep 2024 10:42:23 -0400
Received: by mail-pl1-f172.google.com with SMTP id
 d9443c01a7336-20b1335e4e4so40734285ad.0
 for <72300 <at> debbugs.gnu.org>; Mon, 30 Sep 2024 07:41:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1727707218; x=1728312018; 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=37dc90vS2YiLs6KX2IZ2FELla9A476yYCS3hgHDRGY4=;
 b=IMh1/bpBJ9NTRKcFicFI1qau9hjOejJ6dg01hhVSISQjaOXXZ5PnehT2FrRPUPlI40
 IUHF4Ntr4EHxt3NLpr1BOAYi9oGnVWClu59QVOsD6yGJj7KpPH+3KK0UiSqlyeicpl6+
 rIzqqdZ/ePjxLDuPR0yD0ei+IBXesuR7QmfI/CGYGFYyRZINQ771jfIDuigSlY2wj+Vu
 /CMOUv3uFedc2mrSGupHKdn11fTAxjEGpjxvR/TGugkdn04tx1y8rUg3pqttnT4hyBOa
 4RMmc75rq43qymtCrj/mix3uyAiWaPFUO7ON/QIVX9j7j8MnOUQqTRtshwm5Dc5c3+u7
 wL4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1727707218; x=1728312018;
 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=37dc90vS2YiLs6KX2IZ2FELla9A476yYCS3hgHDRGY4=;
 b=XvLWEqKswe6DJ8kT0oGrvJteFthkqN4YA/olr8BBu0x+IWDCIzoUla0onVO6Tbo24V
 JPQIEskJQKaVZ4w0AkUkMX/3f4EP9JgU8Jevy8fW65KQyaRNNLazsCs9O0qJ3gDKJy9+
 6VcEqUS+sHjTkC4SPUdoIDXF3inS12nOVpI5F/DtGFFfQWB5FiAOYzMaN7w88XLFwgZb
 ATtdwTUO+HNkqzAmeW1f2wHmS9LfFl0cy69JiIPM7sKdMD2wanC0dU3DbN6HP+gZEnws
 PAhlPh0MPVD0iUn9h2tAqldDRT/wG0lxixgXiIqBfyrsksJkrdMFt2lleyIA9/6ORoSF
 64OQ==
X-Forwarded-Encrypted: i=1;
 AJvYcCXCy7Oy0lDnt7CH4iWllTnJRjhwes1ymX8R3n+audqrxQVG7DBFwZE4wG0pUCjZ1mJAwMm5Zw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yyjwi7rapg7PZq7V6OCd+FnbLYd9G/9DnL7X7XivjNRPs6JMonh
 oBvLqmqNG3m6lLDd4wGZ1GGEdhDxe5qAtRpFmw8/CKZL/8KINqJTC9eDjwEi7+XnsU3/eBBdxO3
 tvx/yXQQnGW9qY3tdOrc6NWkm69JLa1W2
X-Google-Smtp-Source: AGHT+IGBDvHQMCYv2GT3sLueCeefM0eeZAPdnT5q933j8PBEef3yrcy+cEyM/rNlTikq9s+InOi0Sh9x0+xEMWsRelo=
X-Received: by 2002:a05:6122:4585:b0:509:e5b5:d133 with SMTP id
 71dfb90a1353d-509e5b5dfb2mr2903280e0c.6.1727706706982; Mon, 30 Sep 2024
 07:31:46 -0700 (PDT)
MIME-Version: 1.0
References: <87r0bh8cy7.fsf@HIDDEN> <86mslssny9.fsf@HIDDEN>
 <CAN+1HbpB28NpJK3EQzyCzupufP5KjQCCOoRUVuHBFQZQWWyRPQ@HIDDEN>
 <04986428-27b5-462d-8f89-139cd56ea117@HIDDEN>
 <CAN+1HbovL9SFG9Pj1gVJg4Xv+yxEA8ciX3LvafNpn25C_k+Cfg@HIDDEN>
 <CAN+1HbpLhn6O9C1QnYQ2_oPExGAuQQsEvOhEayTArv0f2FStjg@HIDDEN>
 <4ecab405-a03f-4dd7-af4b-f2d29b0420a4@HIDDEN>
In-Reply-To: <4ecab405-a03f-4dd7-af4b-f2d29b0420a4@HIDDEN>
From: Ship Mints <shipmints@HIDDEN>
Date: Mon, 30 Sep 2024 10:31:35 -0400
Message-ID: <CAN+1HboyaPRbetLT7EMVg3G8M0cjn7kkskxQ41ojcH9C5GZZdg@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000008bbf7006235710ac"
X-Spam-Score: -0.9 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.9 (-)

--0000000000008bbf7006235710ac
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 29, 2024 at 9:50=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> wro=
te:

> On 13/08/2024 17:50, Ship Mints wrote:
> > As some food for thought, we've used git attributes via "git check-attr=
"
> > to record custom metadata at the repository level to provide hints to
> > tooling. As project.el and other tools evolve, perhaps we can consider
> > the cases where users can supply functions that influence behavior wher=
e
> > one use case is based on things like git attributes. The case in hand i=
s
> > whether a submodule should be considered external to a project.el
> > project such as the vendor/third-party submodule I'd mentioned. We use
> > the default project-vc-merge-submodules t and our exceptions could be
> > encoded via a custom git attribute and indicated via a predicate
> > function, perhaps. In the absence of formal guidelines, and git does no=
t
> > seem to define "reserved words" for naming, we prefix custom attributes
> > with an underscore.
>
> Git attributes is a possible approach, with a downside of extra process
> calls, which over Tramp (for example) would mean additional latency.
>

(defun project--value-in-dir (var dir) already incurs latency over tramp,
right?


> How about we just support filtering out submodules using the
> project-vc-ignores var? Which can be assigned in .dir-locals.el or
> through other means.
>

Seems simple. Perhaps an abnormal hook so people can customize buffer local
hook via dir locals? If they want to use git attributes, they could
integrate that approach as an added/replacement function. The function list
could default to a function that implements current behavior.


> I kind of hoped this would work automatically, it does not, but adding
> the extra comparisons against the list of ignores seems natural enough.
>
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index 599a350e5ce..79fcfb65f87 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -720,7 +731,9 @@ project--vc-list-files
>            (let ((sub-files
>                   (mapcar
>                    (lambda (module)
> -                   (when (file-directory-p module)
> +                   (when (and (file-directory-p module)
> +                              ;; TODO: Support real globs.
> +                              (not (member module extra-ignores)))
>                        (let ((sub-files
>                               (project--vc-list-files
>                                (concat default-directory module)
>
>

--0000000000008bbf7006235710ac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">=
On Sun, Sep 29, 2024 at 9:50=E2=80=AFPM Dmitry Gutov &lt;<a href=3D"mailto:=
dmitry@HIDDEN">dmitry@HIDDEN</a>&gt; wrote:</span><br></div></div><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">O=
n 13/08/2024 17:50, Ship Mints wrote:<br>
&gt; As some food for thought, we&#39;ve used git attributes via &quot;git =
check-attr&quot; <br>
&gt; to record custom metadata=C2=A0at the repository level to provide hint=
s to <br>
&gt; tooling. As project.el and other tools evolve, perhaps we can consider=
 <br>
&gt; the cases where users can supply functions that influence behavior whe=
re <br>
&gt; one use case is based on things like git attributes. The case in hand =
is <br>
&gt; whether a submodule should be considered external to a project.el <br>
&gt; project such as the vendor/third-party submodule I&#39;d mentioned. We=
 use <br>
&gt; the default=C2=A0project-vc-merge-submodules t and our exceptions coul=
d be <br>
&gt; encoded via a custom git attribute and indicated via a predicate <br>
&gt; function,=C2=A0perhaps. In the absence of formal guidelines, and git d=
oes not <br>
&gt; seem to define &quot;reserved words&quot; for naming, we prefix custom=
 attributes <br>
&gt; with an underscore.<br>
<br>
Git attributes is a possible approach, with a downside of extra process <br=
>
calls, which over Tramp (for example) would mean additional latency.<br></b=
lockquote><div><br></div><div>(defun project--value-in-dir (var dir)<span c=
lass=3D"gmail_default" style=3D"font-family:monospace"> already incurs late=
ncy over tramp, right?</span><br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
How about we just support filtering out submodules using the <br>
project-vc-ignores var? Which can be assigned in .dir-locals.el or <br>
through other means.<br></blockquote><div><br></div><div><div class=3D"gmai=
l_default" style=3D"font-family:monospace">Seems simple. Perhaps an abnorma=
l hook so people can customize buffer local hook via dir locals?=C2=A0If th=
ey want to use git attributes, they could integrate that approach as an add=
ed/replacement function. The function list could default to a function that=
 implements current behavior.</div></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
I kind of hoped this would work automatically, it does not, but adding <br>
the extra comparisons against the list of ignores seems natural enough.<br>
<br>
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el<br>
index 599a350e5ce..79fcfb65f87 100644<br>
--- a/lisp/progmodes/project.el<br>
+++ b/lisp/progmodes/project.el<br>
@@ -720,7 +731,9 @@ project--vc-list-files<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(let ((sub-files<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (mapcar<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(lambd=
a (module)<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(when=
 (file-directory-p module)<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(when=
 (and (file-directory-p module)<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; TODO: Support real globs.<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (not (member module extra-ignores)))<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(let ((sub-files<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (project--vc-list-files<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(concat default-directory module)<br>
<br>
</blockquote></div></div>

--0000000000008bbf7006235710ac--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72300: project.el: detect newly created project contained within another
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 30 Sep 2024 23:12:01 +0000
Resent-Message-ID: <handler.72300.B72300.172773787914909 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72300
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ship Mints <shipmints@HIDDEN>
Cc: 72300 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Federico Tedin <federicotedin@HIDDEN>
Received: via spool by 72300-submit <at> debbugs.gnu.org id=B72300.172773787914909
          (code B ref 72300); Mon, 30 Sep 2024 23:12:01 +0000
Received: (at 72300) by debbugs.gnu.org; 30 Sep 2024 23:11:19 +0000
Received: from localhost ([127.0.0.1]:47663 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1svPXy-0003sN-SR
	for submit <at> debbugs.gnu.org; Mon, 30 Sep 2024 19:11:19 -0400
Received: from fout-a3-smtp.messagingengine.com ([103.168.172.146]:35565)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1svPXt-0003sD-Kn
 for 72300 <at> debbugs.gnu.org; Mon, 30 Sep 2024 19:11:17 -0400
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.phl.internal (Postfix) with ESMTP id 157F51380A3E;
 Mon, 30 Sep 2024 19:10:35 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Mon, 30 Sep 2024 19:10:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
 :cc:content-transfer-encoding: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=1727737835;
 x=1727824235; bh=vK8pRjwzl8kkYU62UQjLx3U4i4R1RmzvytHDUeB0Q2k=; b=
 a4IWk7ZzSacrvR8i1FIgYFM3O9StMv8BFv2gyHNEoIPCkQVwlKBnn+Q5Y3gR90FM
 C1cK8Aojwb0KOquDjAC0t/GcYLxsTnybn6P9Vtoe15cmutloRg9Ng6qL3+PHWZ68
 AQMo2VLRY1B/K2en6USGv3f0Py5lVOY3HecYg5cyyE/+OQGEI+wl6xO9SdiFG+qn
 HXUad6DngjeylhActOZR4DmGBZYbF/uGc99rTxtnQxeWzdK+LAyJTMS8Oolx8oWu
 JUxtSopvI/slQmuexkHsljlRWTJPNOUG3CL2B69uF1UH9NtearBO0VBhn3jkiU06
 jiNfdwaWes40MyMxour21g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :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=1727737835; x=
 1727824235; bh=vK8pRjwzl8kkYU62UQjLx3U4i4R1RmzvytHDUeB0Q2k=; b=g
 LdzUgQ7AD74EVjnKqkGw81ZEAUM39mcS+Fk6qIrIYUycUhLe2WXcMpaZPpxeOOzP
 NGXIB5Na/ey1mPdvnEreLXzBaz8bVuagaSC8GjXG8PAKPV5YBlO+xhryrHgnYelb
 07/sHeQCDh1UTH+gCJCp5DeDdKe06NSoUR1L2a4zvpFNekoOgzOTgzvML7rtVEGA
 GFv0r/Sg3rheTUULgekxSwC2Goqxu5Dm0ZYW4hl+5nYOcLgOGnlldcllb7C6U6kL
 dqEYzqqRjgwlcma/6jURitkDXLrw5NqX1HhBsgfonGr+1ZNt6qIX6K5VNZBffFQc
 0ZbKTW1vnJ4NSI84RfQLA==
X-ME-Sender: <xms:6i_7ZuB12P6JVmi1TQd2nDQet-RcvtjKFMab96SaQcqyIazE_8axOw>
 <xme:6i_7ZoiMhy71Yl6yWBNJ1U7pvjAYhR1kr4uijqgr-OvXoCij1b0v4xlc1pBNtsMO7
 QZD-alxx-YQ9hhKDb0>
X-ME-Received: <xmr:6i_7ZhleuQz5lB66nQBU8OWowPlW4o-y9I5VELWdW5l_4tv6SF2hyWPHn67dQ9UINyXD>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdduiedgudelucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdej
 necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug
 gvvheqnecuggftrfgrthhtvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveeg
 tedthefhudekteehffeukeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe
 hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho
 peegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehshhhiphhmihhnthhssehgmh
 grihhlrdgtohhmpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohep
 fhgvuggvrhhitghothgvughinhesghhmgidruggvpdhrtghpthhtohepjedvfedttdesug
 gvsggsuhhgshdrghhnuhdrohhrgh
X-ME-Proxy: <xmx:6i_7ZszyZqcfd5OLWizv8gWCTvi-WL3oku67TTMV6FO1pIYVXwYb7w>
 <xmx:6i_7ZjRtTL1rODai0YtNIu43zQx_Q0I7Qfuq6lbPXgVfot77Nt578g>
 <xmx:6i_7ZnbTfYjobeJSUDbXSbEeTNc0qFHhBqyTMEPfh9V2J9X3ipJ3yw>
 <xmx:6i_7ZsSe9OBdbNHIR0oAGq_liWFwLy3ywdhoOzjU4ccU0KyU5_rOww>
 <xmx:6y_7ZhPCafHud0BwAZVo1oNFhj1SSiKQO1y00i_ByRa887-NT7D1dMw6>
Feedback-ID: i07de48aa:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 30 Sep 2024 19:10:33 -0400 (EDT)
Message-ID: <6423009d-777f-453d-94e0-22c095b62d9a@HIDDEN>
Date: Tue, 1 Oct 2024 02:10:31 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <87r0bh8cy7.fsf@HIDDEN> <86mslssny9.fsf@HIDDEN>
 <CAN+1HbpB28NpJK3EQzyCzupufP5KjQCCOoRUVuHBFQZQWWyRPQ@HIDDEN>
 <04986428-27b5-462d-8f89-139cd56ea117@HIDDEN>
 <CAN+1HbovL9SFG9Pj1gVJg4Xv+yxEA8ciX3LvafNpn25C_k+Cfg@HIDDEN>
 <CAN+1HbpLhn6O9C1QnYQ2_oPExGAuQQsEvOhEayTArv0f2FStjg@HIDDEN>
 <4ecab405-a03f-4dd7-af4b-f2d29b0420a4@HIDDEN>
 <CAN+1HboyaPRbetLT7EMVg3G8M0cjn7kkskxQ41ojcH9C5GZZdg@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <CAN+1HboyaPRbetLT7EMVg3G8M0cjn7kkskxQ41ojcH9C5GZZdg@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

On 30/09/2024 17:31, Ship Mints wrote:

>     Git attributes is a possible approach, with a downside of extra process
>     calls, which over Tramp (for example) would mean additional latency.
> 
> 
> (defun project--value-in-dir (var dir)already incurs latency over tramp, 
> right?

Yep, but almost every other separate I/O adds to it. So with other 
things equal, I'd prefer solutions with fewer disk reads - at least for 
the default behavior.

>     How about we just support filtering out submodules using the
>     project-vc-ignores var? Which can be assigned in .dir-locals.el or
>     through other means.
> 
> 
> Seems simple. Perhaps an abnormal hook so people can customize buffer 
> local hook via dir locals? If they want to use git attributes, they 
> could integrate that approach as an added/replacement function. The 
> function list could default to a function that implements current behavior.

I'd like to say yes, but what would be a good place and name for that hook?

Note there is an existing hook called before-hack-local-variables-hook 
which allows one to alter the applied local variables. But that one 
might run more often than ideal - perhaps try it out and report back.

Another approach might use a custom project backend which wraps the 
existing project-vc - it would need to provide a custom implementation 
for 'project-ignores' and could delegate the rest of the methods to the 
parent.

BTW, are you asking about using git attributes because there is an 
existing workflow that somehow hooks into it, at some of your clients? 
If not, then editing dir-locals.el to set the value of 
project-vc-ignores directly seems like an easier approach.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72300: project.el: detect newly created project contained within another
Resent-From: Ship Mints <shipmints@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Oct 2024 20:22:01 +0000
Resent-Message-ID: <handler.72300.B72300.17278140862957 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72300
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: 72300 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Federico Tedin <federicotedin@HIDDEN>
Received: via spool by 72300-submit <at> debbugs.gnu.org id=B72300.17278140862957
          (code B ref 72300); Tue, 01 Oct 2024 20:22:01 +0000
Received: (at 72300) by debbugs.gnu.org; 1 Oct 2024 20:21:26 +0000
Received: from localhost ([127.0.0.1]:53443 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1svjN7-0000lP-9K
	for submit <at> debbugs.gnu.org; Tue, 01 Oct 2024 16:21:26 -0400
Received: from mail-ua1-f54.google.com ([209.85.222.54]:51509)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <shipmints@HIDDEN>) id 1svjN4-0000j9-8W
 for 72300 <at> debbugs.gnu.org; Tue, 01 Oct 2024 16:21:23 -0400
Received: by mail-ua1-f54.google.com with SMTP id
 a1e0cc1a2514c-84e8bb409b6so1924085241.3
 for <72300 <at> debbugs.gnu.org>; Tue, 01 Oct 2024 13:21:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1727814017; x=1728418817; 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=1g9SyoEpDHmzBnAkiAPr8NFjd66X+DsmApD7yGP4p9Y=;
 b=fhDB1FhLZnWrcCpvx2vgBL1QO+l8T+dGRHzj/qWVm069MjIQj8uJ5phOWX4urHn1ai
 vtvJyevYEIGZTd8o4gKh/hgAv32mYpsF/E+TxlOBhLP2w4W9afUypD4VYlF22Vtbniv6
 wmGGn7wttPylp4I/b7naXPeLMbVxWpu7NGULmEt9blXgLh4NJzXg6U+Lz4Z8MVFBax3o
 zCKQKrYlqX9t23CEra+lHPv5lCSb53yyvWqjTiU1PuNAceX79r178UKMDbZMbTfkiuAq
 0VJhBWx7Zu/+iHVf7X8kkaG0uzIjWjnPWjZclgOVhQxFl6HUgvX1rRq3WseHFJbiM0qt
 xWRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1727814017; x=1728418817;
 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=1g9SyoEpDHmzBnAkiAPr8NFjd66X+DsmApD7yGP4p9Y=;
 b=pwocYFiF3NOVdtruyaRLyWxNlZNepWYoCCRu59N5fPc3cp0K5RUZirbb4aUA7/oDij
 lGvxrZR45bwEk1S6s5PnBPnmR5/IbG/9YHhXEyivgozCDSgsRImGjEP7CtTYWtudS9sN
 s1xz/u5U3eWe7vF0g/VH9Ll83+5H4d1zJNUTYsAfvye2lJ7G+YrgP6I0MK7nf2YHX9Z4
 J9/R2XJ5UQpEpYKkjtpWB0oz8MJA5GnJYut53LJk06WiFDw4rcFfkQui2iYNW0kxTK8x
 ebYC/kPnFptZug1DYyO3ZBN/ugkZ8F1WGDuJVNzxt5+tifgyYa5NvJ4/NvLFI5jZWX1G
 vZQw==
X-Forwarded-Encrypted: i=1;
 AJvYcCVI+kXjADui+W+sW7PcdbhmprcHA7/2u8w6Qk0ttQ8cnU/4RUS2bTBbYjNV0msGV0yrRrzVvg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yxui1dH7ohtyA2Y316YcgrAmxMIlmgH9wE/DLcptFkZ1duGS6Cn
 euHczot7eA8BSrs44X4PUV43Inul7fhuEo0QdldK0jbNiEAkAGL30scXjDMpbGFmkTf5E8RhMVI
 Zaq0vueGWAZEiCqzQvWRRqltw7E4=
X-Google-Smtp-Source: AGHT+IEmnKyjmsp0PZ/oXb0g5K2w5cYbmIqZ3fGAg1vSHdz4bMOCccW7uchropBQmoEzyr772ZICU6RADyqSy9dptlM=
X-Received: by 2002:a05:6102:dcc:b0:493:de37:b3ef with SMTP id
 ada2fe7eead31-4a3e6855b10mr907842137.13.1727814016794; Tue, 01 Oct 2024
 13:20:16 -0700 (PDT)
MIME-Version: 1.0
References: <87r0bh8cy7.fsf@HIDDEN> <86mslssny9.fsf@HIDDEN>
 <CAN+1HbpB28NpJK3EQzyCzupufP5KjQCCOoRUVuHBFQZQWWyRPQ@HIDDEN>
 <04986428-27b5-462d-8f89-139cd56ea117@HIDDEN>
 <CAN+1HbovL9SFG9Pj1gVJg4Xv+yxEA8ciX3LvafNpn25C_k+Cfg@HIDDEN>
 <CAN+1HbpLhn6O9C1QnYQ2_oPExGAuQQsEvOhEayTArv0f2FStjg@HIDDEN>
 <4ecab405-a03f-4dd7-af4b-f2d29b0420a4@HIDDEN>
 <CAN+1HboyaPRbetLT7EMVg3G8M0cjn7kkskxQ41ojcH9C5GZZdg@HIDDEN>
 <6423009d-777f-453d-94e0-22c095b62d9a@HIDDEN>
In-Reply-To: <6423009d-777f-453d-94e0-22c095b62d9a@HIDDEN>
From: Ship Mints <shipmints@HIDDEN>
Date: Tue, 1 Oct 2024 16:20:05 -0400
Message-ID: <CAN+1Hbq3fFqr8UiTTiZFsLCLoCu=qZdqFmwUGahJZYRJvJms0A@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000b58ae50623700c24"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000b58ae50623700c24
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 30, 2024 at 7:10=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> wro=
te:

> On 30/09/2024 17:31, Ship Mints wrote:
>
> >     Git attributes is a possible approach, with a downside of extra
> process
> >     calls, which over Tramp (for example) would mean additional latency=
.
> >
> >
> > (defun project--value-in-dir (var dir)already incurs latency over tramp=
,
> > right?
>
> Yep, but almost every other separate I/O adds to it. So with other
> things equal, I'd prefer solutions with fewer disk reads - at least for
> the default behavior.
>

Indeed. It would likely have to be a shell-command-to-string via a tramp
file name form.


> >     How about we just support filtering out submodules using the
> >     project-vc-ignores var? Which can be assigned in .dir-locals.el or
> >     through other means.
> >
> >
> > Seems simple. Perhaps an abnormal hook so people can customize buffer
> > local hook via dir locals? If they want to use git attributes, they
> > could integrate that approach as an added/replacement function. The
> > function list could default to a function that implements current
> behavior.
>
> I'd like to say yes, but what would be a good place and name for that hoo=
k?
>
> Note there is an existing hook called before-hack-local-variables-hook
> which allows one to alter the applied local variables. But that one
> might run more often than ideal - perhaps try it out and report back.
>

I'll dig back into project.el code and take a look when I have some focus
to think this through.


> Another approach might use a custom project backend which wraps the
> existing project-vc - it would need to provide a custom implementation
> for 'project-ignores' and could delegate the rest of the methods to the
> parent.
>

Also possible. I wonder if this is what Spencer wound up doing to defray
the cost of running "find" on a large hierarchy.


> BTW, are you asking about using git attributes because there is an
> existing workflow that somehow hooks into it, at some of your clients?
> If not, then editing dir-locals.el to set the value of
> project-vc-ignores directly seems like an easier approach.
>

I've used git attributes as semaphores for subdirectories in a monorepo to
identify subprojects (which are not necessarily git submodules, but we have
those, too). This helps with certain tooling external to Emacs. Sadly
git-attr, it doesn't have a simple exit with 0 for success, non-zero for
failure/missing attribute so needs a little parser for its results. The use
cases for git attributes in a monorepo help segregate workflows among front
end, back end, firmware subprojects, among others, where tooling is pretty
different (and developer skill levels) and there are different workflows. I
think I mentioned once before that there is no naming convention for custom
git attributes that I'm aware of so I simply prefix ours with an
underscore. So far, they're just semaphores where we look for check-attr
output of "unspecified" vs. any value for a file/directory of interest.

I haven't been that focused on this aspect in a while. I think there are
some potentially tricky things to think through as I sense that project.el
is becoming more closely tied to vc integration than mere project file
association. In the past (I think on github), I talked about using a meta
project to graft together disparate directory hierarchies for user
convenience beyond just symlinks, though those work, when maintained. e.g.,
how does one find files that are conceptually common to a project that
don't share a directory hierarchy root. The biggest example here is that
user/admin/management documentation lives in cloud drives, while source
code lives locally (via git, mostly). People work across those boundaries.
There are meta project files in each disparate root, .project.meta files
which all contain the same text to graft them together using tools we have.
Some people put in symlinks (like me, I'm lazy) and that helps but not
everyone shares the precise directory hierarchies across every machine
making symlinks harder to deal with when checked into git (and there are
Windows users). This may be a use case that project.el should never
address, not sure.

Only concrete, defensible and not-too-esoteric use cases matter, of course.

-Stephane

--000000000000b58ae50623700c24
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">=
On Mon, Sep 30, 2024 at 7:10=E2=80=AFPM Dmitry Gutov &lt;<a href=3D"mailto:=
dmitry@HIDDEN">dmitry@HIDDEN</a>&gt; wrote:</span><br></div></div><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">O=
n 30/09/2024 17:31, Ship Mints wrote:<br>
<br>
&gt;=C2=A0 =C2=A0 =C2=A0Git attributes is a possible approach, with a downs=
ide of extra process<br>
&gt;=C2=A0 =C2=A0 =C2=A0calls, which over Tramp (for example) would mean ad=
ditional latency.<br>
&gt; <br>
&gt; <br>
&gt; (defun project--value-in-dir (var dir)already incurs latency over tram=
p, <br>
&gt; right?<br>
<br>
Yep, but almost every other separate I/O adds to it. So with other <br>
things equal, I&#39;d prefer solutions with fewer disk reads - at least for=
 <br>
the default behavior.<br></blockquote><div>=C2=A0</div><div><div class=3D"g=
mail_default" style=3D"font-family:monospace">Indeed. It would likely have =
to be a shell-command-to-string via a tramp file name form.</div></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt;=C2=A0 =C2=A0 =C2=A0How about we just support filtering out submodules =
using the<br>
&gt;=C2=A0 =C2=A0 =C2=A0project-vc-ignores var? Which can be assigned in .d=
ir-locals.el or<br>
&gt;=C2=A0 =C2=A0 =C2=A0through other means.<br>
&gt; <br>
&gt; <br>
&gt; Seems simple. Perhaps an abnormal hook so people can customize buffer =
<br>
&gt; local hook via dir locals?=C2=A0If they want to use git attributes, th=
ey <br>
&gt; could integrate that approach as an added/replacement function. The <b=
r>
&gt; function list could default to a function that implements current beha=
vior.<br>
<br>
I&#39;d like to say yes, but what would be a good place and name for that h=
ook?<br>
<br>
Note there is an existing hook called before-hack-local-variables-hook <br>
which allows one to alter the applied local variables. But that one <br>
might run more often than ideal - perhaps try it out and report back.<br></=
blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"font-f=
amily:monospace">I&#39;ll dig back into project.el code and take a look whe=
n I have some focus to think this through.</div></div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">
Another approach might use a custom project backend which wraps the <br>
existing project-vc - it would need to provide a custom implementation <br>
for &#39;project-ignores&#39; and could delegate the rest of the methods to=
 the <br>
parent.<br></blockquote><div>=C2=A0</div><div><div class=3D"gmail_default" =
style=3D"font-family:monospace">Also possible. I wonder if this is what Spe=
ncer wound up doing to defray the cost of running &quot;find&quot; on a lar=
ge hierarchy.</div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">
BTW, are you asking about using git attributes because there is an <br>
existing workflow that somehow hooks into it, at some of your clients? <br>
If not, then editing dir-locals.el to set the value of <br>
project-vc-ignores directly seems like an easier approach.<br></blockquote>=
<div><br></div><div class=3D"gmail_default" style=3D"font-family:monospace"=
>I&#39;ve used git attributes as semaphores for subdirectories in a monorep=
o to identify subprojects (which are not necessarily git submodules, but we=
 have those, too). This helps with certain tooling external to Emacs. Sadly=
 git-attr, it doesn&#39;t have a simple exit with 0 for success, non-zero f=
or failure/missing attribute so needs a little parser for its results. The =
use cases for git attributes in a monorepo help segregate workflows among f=
ront end, back end, firmware subprojects, among others, where tooling is pr=
etty different (and developer skill levels) and there are different workflo=
ws. I think I mentioned once before that there is no naming convention for =
custom git attributes that I&#39;m aware of so I simply prefix ours with an=
 underscore. So far, they&#39;re just semaphores where we look for check-at=
tr output of &quot;unspecified&quot; vs. any value for a file/directory of =
interest.</div><div class=3D"gmail_default" style=3D"font-family:monospace"=
><br></div><div class=3D"gmail_default" style=3D"font-family:monospace">I h=
aven&#39;t been that focused on this aspect in a while. I think there are s=
ome potentially tricky things to think through as I sense that project.el i=
s becoming more closely tied to vc integration than mere project file assoc=
iation. In the past (I think on github), I talked about using a meta projec=
t to graft together disparate directory hierarchies for user convenience be=
yond just symlinks, though those work, when maintained. e.g., how does one =
find files that are conceptually common to a project that don&#39;t share a=
 directory hierarchy root. The biggest example here is that user/admin/mana=
gement documentation lives in cloud drives, while source code lives locally=
 (via git, mostly). People work across those boundaries. There are meta pro=
ject=C2=A0files in each disparate root, .project.meta files which all conta=
in the same text to=C2=A0graft them together using tools we have. Some peop=
le put in symlinks (like me, I&#39;m lazy) and that helps but not everyone =
shares the precise directory hierarchies across every machine making symlin=
ks harder to deal with when checked into git (and there are Windows users).=
 This may be a use case that project.el should never address, not sure.</di=
v><div class=3D"gmail_default" style=3D"font-family:monospace"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:monospace">Only concrete, d=
efensible and not-too-esoteric use cases matter, of course.</div><div class=
=3D"gmail_default" style=3D"font-family:monospace"><br></div><div class=3D"=
gmail_default" style=3D"font-family:monospace">-Stephane</div></div></div>

--000000000000b58ae50623700c24--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72300: project.el: detect newly created project contained within another
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Oct 2024 21:46:02 +0000
Resent-Message-ID: <handler.72300.B72300.172781913417087 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72300
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ship Mints <shipmints@HIDDEN>
Cc: 72300 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Federico Tedin <federicotedin@HIDDEN>
Received: via spool by 72300-submit <at> debbugs.gnu.org id=B72300.172781913417087
          (code B ref 72300); Tue, 01 Oct 2024 21:46:02 +0000
Received: (at 72300) by debbugs.gnu.org; 1 Oct 2024 21:45:34 +0000
Received: from localhost ([127.0.0.1]:53868 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1svkgX-0004RX-D6
	for submit <at> debbugs.gnu.org; Tue, 01 Oct 2024 17:45:33 -0400
Received: from fhigh-a7-smtp.messagingengine.com ([103.168.172.158]:58549)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1svkgW-0004RO-0c
 for 72300 <at> debbugs.gnu.org; Tue, 01 Oct 2024 17:45:32 -0400
Received: from phl-compute-09.internal (phl-compute-09.phl.internal
 [10.202.2.49])
 by mailfhigh.phl.internal (Postfix) with ESMTP id C336911400EC;
 Tue,  1 Oct 2024 17:45:26 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-09.internal (MEProxy); Tue, 01 Oct 2024 17:45:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
 :cc:content-transfer-encoding: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=1727819126;
 x=1727905526; bh=9+uhvtuBwyQo7lPoDC53acr5jCD9plYBLkz+K53q5BU=; b=
 HFdFmx3Ll16YwZkSFlRfGEaxhGSIYA8jM1T8sk7AGEoFSEdojoxVtjB6CAbrrosM
 pj74D2MNTk4ZZN+yk9xpl3MIc8uHNyxM/oBNAYGzCbhxoQc6xybOrQCcbMLXfXAC
 YrFEKKK2/ArdTElHQw4FEdmDsAWaq0YQU6pSlhnHVjwLsYudtLzYgCpTr8btdq49
 rKUeauV2OJqynWVvKcwCZGBGJodDzyOuodpuLc/K4GvC5Cd5jWV1llAwidT6eEYt
 D+MQkCPx+FYYxfIHG8FfctThrEe3p1QwpkM+WhiWnoxpLouHuoCc85kjETzMtUu4
 T6FygKoiEwt47bYSCExBog==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :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=1727819126; x=
 1727905526; bh=9+uhvtuBwyQo7lPoDC53acr5jCD9plYBLkz+K53q5BU=; b=E
 tMkqE1iwBIyvsXEhFNJr8EBzXwAG0bP9KP1hnzzhnQxVAmJFy+u1unvH0L+f7qLL
 zvMKZtjH+R0Z5rHtD48iEWwEXAKe46ab8Z1FSjVSXPC0qVDNi8S3N5hrzbQoJkGS
 yaortU9D8QxTqDWNY6inRTUug5xX+pPsyYScvxiCiAf0iUVFz9FnmwvrA5TsOwVn
 G0oooPAtimyQBwGmWhrdoYocG8OCJVDgq0dYQydMFva5GrpNGva1QWDNbCLCDjRs
 WGEtxJ1wdyaog9SRWm2r4TTxZi7xJZ5LbUX0yUz1mjiO2ZNeNNdk7LgWKdKEqK8A
 gOTrcIbmCP+EeVvEmmxGQ==
X-ME-Sender: <xms:dm38Zm9I9REZ79k7QhEtMG3HKq91ihM-WNvVShhmpt-7du55nnbBiw>
 <xme:dm38ZmutzVRiWUGL0Z94t0muUdFMf4Ha-dSAXAMokE0VCF44mJ9eShcJJLm5B2eLH
 S6WsxslvuzOts9KIdk>
X-ME-Received: <xmr:dm38ZsBQZYVpTaPGG9Na8v6JBR88Iz_9TEwxsurmTd0mt7VQVtc0-fxksnN1d4tdiVs>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddukedgtddvucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdej
 necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug
 gvvheqnecuggftrfgrthhtvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveeg
 tedthefhudekteehffeukeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe
 hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho
 peegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehshhhiphhmihhnthhssehgmh
 grihhlrdgtohhmpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohep
 fhgvuggvrhhitghothgvughinhesghhmgidruggvpdhrtghpthhtohepjedvfedttdesug
 gvsggsuhhgshdrghhnuhdrohhrgh
X-ME-Proxy: <xmx:dm38ZudNkwjDWznQV_COeG6S6vx5ZVqvArgZHh0NBJ8ur9EJAArxOw>
 <xmx:dm38ZrN57V3MjPdcHzHeb4LI9BaDj8UQ_m4QLfkH8vp9NenQtZmn-w>
 <xmx:dm38Zok_XkUAr4AxSggDneDW-0vrigGGVOehmwJlZZ_W9TKv-nDxHg>
 <xmx:dm38Ztu0HwlWQ8djfOMPx_HvvJK3A8P-9yI-Jb9WlAfjzzmc2GlaRg>
 <xmx:dm38ZgrkAlytO346AiPu1PdjNaNa0nw_ptx_f0canB96NPH43W3nHSzE>
Feedback-ID: i07de48aa:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 1 Oct 2024 17:45:22 -0400 (EDT)
Message-ID: <7c8d0eb4-9b8b-4679-bc38-b3d2caaa11bf@HIDDEN>
Date: Wed, 2 Oct 2024 00:45:17 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <87r0bh8cy7.fsf@HIDDEN> <86mslssny9.fsf@HIDDEN>
 <CAN+1HbpB28NpJK3EQzyCzupufP5KjQCCOoRUVuHBFQZQWWyRPQ@HIDDEN>
 <04986428-27b5-462d-8f89-139cd56ea117@HIDDEN>
 <CAN+1HbovL9SFG9Pj1gVJg4Xv+yxEA8ciX3LvafNpn25C_k+Cfg@HIDDEN>
 <CAN+1HbpLhn6O9C1QnYQ2_oPExGAuQQsEvOhEayTArv0f2FStjg@HIDDEN>
 <4ecab405-a03f-4dd7-af4b-f2d29b0420a4@HIDDEN>
 <CAN+1HboyaPRbetLT7EMVg3G8M0cjn7kkskxQ41ojcH9C5GZZdg@HIDDEN>
 <6423009d-777f-453d-94e0-22c095b62d9a@HIDDEN>
 <CAN+1Hbq3fFqr8UiTTiZFsLCLoCu=qZdqFmwUGahJZYRJvJms0A@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <CAN+1Hbq3fFqr8UiTTiZFsLCLoCu=qZdqFmwUGahJZYRJvJms0A@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

On 01/10/2024 23:20, Ship Mints wrote:
> On Mon, Sep 30, 2024 at 7:10 PM Dmitry Gutov <dmitry@HIDDEN 
> <mailto:dmitry@HIDDEN>> wrote:
> 
>     On 30/09/2024 17:31, Ship Mints wrote:
> 
>      >     Git attributes is a possible approach, with a downside of
>     extra process
>      >     calls, which over Tramp (for example) would mean additional
>     latency.
>      >
>      >
>      > (defun project--value-in-dir (var dir)already incurs latency over
>     tramp,
>      > right?
> 
>     Yep, but almost every other separate I/O adds to it. So with other
>     things equal, I'd prefer solutions with fewer disk reads - at least for
>     the default behavior.
> 
> Indeed. It would likely have to be a shell-command-to-string via a tramp 
> file name form.

With a file name handler, then? I suppose it's a possibility.

>      >     How about we just support filtering out submodules using the
>      >     project-vc-ignores var? Which can be assigned in .dir-
>     locals.el or
>      >     through other means.
>      >
>      >
>      > Seems simple. Perhaps an abnormal hook so people can customize
>     buffer
>      > local hook via dir locals? If they want to use git attributes, they
>      > could integrate that approach as an added/replacement function. The
>      > function list could default to a function that implements current
>     behavior.
> 
>     I'd like to say yes, but what would be a good place and name for
>     that hook?
> 
>     Note there is an existing hook called before-hack-local-variables-hook
>     which allows one to alter the applied local variables. But that one
>     might run more often than ideal - perhaps try it out and report back.
> 
> 
> I'll dig back into project.el code and take a look when I have some 
> focus to think this through.

Thanks, looking forward to it.

>     Another approach might use a custom project backend which wraps the
>     existing project-vc - it would need to provide a custom implementation
>     for 'project-ignores' and could delegate the rest of the methods to the
>     parent.
> 
> Also possible. I wonder if this is what Spencer wound up doing to defray 
> the cost of running "find" on a large hierarchy.

Not sure. We're still working on measures aiming to improve performance 
in general, anyway.

>     BTW, are you asking about using git attributes because there is an
>     existing workflow that somehow hooks into it, at some of your clients?
>     If not, then editing dir-locals.el to set the value of
>     project-vc-ignores directly seems like an easier approach.
> 
> 
> I've used git attributes as semaphores for subdirectories in a monorepo 
> to identify subprojects (which are not necessarily git submodules, but 
> we have those, too). This helps with certain tooling external to Emacs. 
> Sadly git-attr, it doesn't have a simple exit with 0 for success, non- 
> zero for failure/missing attribute so needs a little parser for its 
> results. The use cases for git attributes in a monorepo help segregate 
> workflows among front end, back end, firmware subprojects, among others, 
> where tooling is pretty different (and developer skill levels) and there 
> are different workflows. I think I mentioned once before that there is 
> no naming convention for custom git attributes that I'm aware of so I 
> simply prefix ours with an underscore. So far, they're just semaphores 
> where we look for check-attr output of "unspecified" vs. any value for a 
> file/directory of interest.
> 
> I haven't been that focused on this aspect in a while. I think there are 
> some potentially tricky things to think through as I sense that 
> project.el is becoming more closely tied to vc integration than mere 
> project file association.

We can talk about project.el, and we can talk about the project-vc 
backend (the "VC-Aware backend", better called). These two are not the 
same, though naturally related. That's one of the complexities - should 
we add a variable to the one or to the other, for example.

 > In the past (I think on github), I talked > about using a meta 
project to graft together disparate directory
> hierarchies for user convenience beyond just symlinks, though those 
> work, when maintained. e.g., how does one find files that are 
> conceptually common to a project that don't share a directory hierarchy 
> root. The biggest example here is that user/admin/management 
> documentation lives in cloud drives, while source code lives locally 
> (via git, mostly). People work across those boundaries. There are meta 
> project files in each disparate root, .project.meta files which all 
> contain the same text to graft them together using tools we have. Some 
> people put in symlinks (like me, I'm lazy) and that helps but not 
> everyone shares the precise directory hierarchies across every machine 
> making symlinks harder to deal with when checked into git (and there are 
> Windows users). This may be a use case that project.el should never 
> address, not sure.

Maybe not never, but it's currently not very tailored to it. You could 
use project-external-roots, but that part is not so integrated.

Or again, a custom backend could wrap that well enough. Some callers of 
project.el rely on the project being contained in its root dir, but most 
do not.

Last modified: Sun, 12 Jan 2025 05:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.