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

[Dmitry Gutov <dgutov@yandex.ru>]

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?