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

[Dmitry Gutov]

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.

> > And even if we do, we might not need the additional notion of
> > sub-projects. E.g. 'search in the parent project (if any)' might work
> > as "take the root, go up a directory, search for a project there; if
> > it exists, use it". Though Stephen L. might want a generic for that,
> > since his projects do not correlate with directory tree.
> And in my case, sub-projects don't necessarily exist exactly one-level
> down super-project's root.  Sometimes they do, but now always.

I don't think that's important whether it's one-level down exactly:

(defun project-parent (project)
  (project-current nil (file-name-as-directory
                        (file-name-directory
                         (directory-file-name (project-root project))))))

> > If we wanted to define projects and subprojects through the same hook,
> > the step "get all subprojects of the current project" might not be
> > feasible to implement. Because of performance-related considerations.
> Those remain to be seen, I can't guess what things you're imagining.

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.

I wrote about this in another email here yesterday.