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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 2 Dec 2022 03:32:42 +0200
> Cc: monnier@iro.umontreal.ca, danny@dfreeman.email, eric@ericabrahamsen.net,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> Still, if you do want to inherit from 'VC-aware', we can make a public 
> constructor for it. Probably after Emacs 29 is released, and we can see 
> that the structure is settled (it's looking this way now).
> 
> As for 'transient', well, the constructor can be added as well. The 
> structure is stable and least likely to change; unless we just make an 
> executive decision to turn them all into structs or whatever. I just 
> didn't want to encourage people using it -- even Joao's usage is odd 
> because he not only calls the 'project-root' function, but also 
> 'project-files', and it's just luck that its behavior suits his current 
> goals.

I'm just surprised that a simple request to be able to create a project type
that is not one of the 2 built-in types is not answered by a simple "use
this and that APIs".  project.el strives very hard to be generic, but what
is the use in doing that if extending it by 3rd-party code is so
complicated, and on top of that is not already available?

So yes, I think we do have public constructors and whatever else could be
reasonably needed if one wants to subclass either of the two built-in
project types.  For this purpose, I don't think it matters how rich the
built-in type is -- that is something for the sub-classing application to
worry about.  We just need to give them enough rope, and leave the rest up
to them, IMO.