bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project

[Dmitry Gutov]

On 29/11/2022 11:46, João Távora wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > On 26/11/22 21:23, João Távora wrote:
> > > On Sat, Nov 26, 2022, 12:30 Dmitry Gutov <dgutov@yandex.ru
> > > <mailto:dgutov@yandex.ru>> wrote:
> > >       > My use case is the following: I'm interested in being able to
> > >      designate
> > >       > projects (through various means, not only marker files) that may only
> > >       > exist inside other projects.
> > >      You previously described your super-project and how you handled
> > > it
> > >      using
> > >      project-find-functions hook with a new element that looked for file
> > >      markers. Does this patch make that easier to do? Without writing custom
> > >      functions?
> > > The example i gave did _not_ use file markers. Personally, I can't
> > > use them. I need some elisp way.
> >
> > Please elaborate.
>
> I've already elaborated, with actual code.
>
> https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01505.html
> https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01530.html

These answered the question of *what* you want to do, not *why*.

> > Does it mean that those subprojects are chosen manually and don't have
> > "packages.jon" or etc exactly (or that too many subprojects in that
> > same project would, undesirably, contain the same files)?
>
> OK, one last time: packages.json and i.e. monorepos that have a
> developing collection of similarly structured NPM packages that move
> around is good case for marker files, undoubtedly.  I'm not putting that
> into question.
>
> But many times that's not the case and you have a big project in which a
> mostly fixed heterogenous collection of sub-hierarchies exist and you
> would like to designate as those as subprojects.  In the latter case,
> marker files are useless, uselessly slow and perhaps even impossible.

I understand that in theory, it's just it's often possible to solve the 
problem with the tools at hand (see my latest reply on emacs-devel about 
the Emacs doc/ subdirectory). So I figured to ask about your particulars.

> In _both_ cases, it's very useful to have project operations let the
> user choose the target: super-project or sub-project (or "parent
> project", "outer project", "nested project", "inner project": I don't
> care too much about the nomenclature).

Yes. But separate feature.

> > Would being able to set to absolute file names (directories) help? Or
> > would that be too awkward?
>
> That's more or less the idea, but they don't need to be absolute file
> names which is indeed awkward See project-sub-project-prefixes in the
> code I posted.  project-sub-project-prefixes can even be a regex pattern
> applied on the super-project's root.  This describes the heterogenous
> collection economically and robustly.  It is then typically set
> dir-locally, with either a .dir-locals.el file or with
> dir-locals-set-class-variables.

I asked about absolute file names because those would be easier 
(semantically) to cram into the same user option as the markers.

Otherwise we'd need a separate option for those.

Although... if we insisted on using the format like "./abc/def/", that 
would also put those values into a different category. The handling 
logic would need to be different just the same.

> Of course, the member of project-find-functions that consults
> project-sub-project-prefixes needs to be aware of containing
> super-projects found by some other means (marker files included).  See
> the code I posted to emacs-devel for a possible implementation.

Have you tried the patch that I sent in the GP email?