Re: Subprojects in project.el (Was: Eglot, project.el, and python virtual environments)

[Dmitry Gutov <dgutov@yandex.ru>]

On 24/11/22 10:50, João Távora wrote:
> On Thu, Nov 24, 2022 at 3:01 AM Dmitry Gutov <dgutov@yandex.ru 
> <mailto:dgutov@yandex.ru>> wrote:
> 
>     On 23/11/22 15:57, João Távora wrote:
>      >> It would be much more helpful in a dedicated bug report where we
>     could
>      >> discuss the details, collect the votes and see what kind of design
>      >> will ultimately satisfy the requirements. Instead of drowning it all
>      >> in this thread, which is only moderately related.
>      > I think we're doing fine here but I've changed the subject line to
>      > "unbury" it from the thread.
> 
>     You're fussy about proper bug reporting in your projects, but
>     somehow do
>     not extend that courtesy to others.
> 
> 
> I am indeed "fussy" about "bug reporting".  But here, Dmitry, I am not
> reporting a bug.  There's no minimum reproducible recipe, no error
> to report, no surprising behaviour, etc. to speak of.  We're just
> discussing Emacs development... in the emacs-devel mailing list.

You are making a new feature request. Or at least were (when you were 
talking about "subprojects" as a new noun for project.el to have, with 
new associated behaviors).

Since we're back to examining customizable ways to mark projects, I 
invite you to read 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#82 too.

> I can't understand what is discourteous about this.

That would be not following the procedure the maintainer has asked you 
to follow.

>     I'm imagining that traversing a directory tree with an arbitrary
>     predicate is going to be slow. If the predicate is limited somehow
>     (e.g.
>     to a list of "markers" as base file name, or at least wildcards), 'git
>     ls-files' can probably handle this, with certain but bounded cost.
> 
> 
> If the user wants marker files to mark the roots of subprojects, we'll
> have to access the file system eventually because that's where
> that information lives.  It would be a minimal and essential access.  If the
> user is discontent with that performance hit (I really doubt it), then
> the user may use other means to mark roots of subprojects, like
> the one I suggested earlier.
> 
> In particular, I don't understand where "traversing a directory tree" comes
> in.  That part is completely absent from the solution I am putting forth.

Your solution looks very similar to the patch in 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#85, which see.

Note that I have replied to your solution as well with a couple of 
questions, related to what is already written in the bug above.

I don't really know what "the user wants". People apparently find this 
discussion too scary or meandering to provide any additional input. The 
several who I asked to comment have walked away perplexed. Or perhaps 
it's just Debbugs.

People do seem it natural to express their custom project structures via 
file markers, at least that's what I see in the wild as 
project-find-functions customizations.

They have an upside: it's economical to customize markers once, and then 
have them used for every project of yours, instead of having to edit 
dir-locals.el everywhere where needed. But the downside is that 
implementing the non-intersecting model of project becomes expensive: in 
the most general case one will have to traverse the dir tree to find the 
inner projects to exclude them. But if the markers are plain file names 
or wildcards, optimizations are possible (e.g. 'git ls-files'; which is 
still not instant, however), at least for Git/Hg parent projects.

The idea of customizing the projects with a list of relative subproject 
directory file names solves those downsides, but comes with lack of 
automation: you have to do it for every relevant project, and not forget 
to update the settings as the project structure changes. Which might 
also be a pain e.g. when switching branches, if your dir-locals.el is 
not checked in.

Perhaps we'll ultimately end up with both ways to do this inside 
project.el, but that feels redundant.