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

[Nikolay Kudryavtsev]

> But when we go up a directory, "./project/". And when asked to list 
> its files, how do we avoid including "./project/foo/a" in that list? 
> It would make sense to exclude any nested projects, right?
Not necessarily. It may be a useful thing to do for some projects, but 
it does not follow from anything that it should be the only or the 
default option. The correct solution here is IMHO implementing some kind 
of .project-settings.el file in which you can set hide-nested-project-files.

> Setting project-find-functions in a major mode is a questionable thing 
> to do, because then you end up with Emacs where files in the same 
> directory belong to different projects.
I'm not talking about setting it locally in the mode, more about modes 
providing such functions on load. That's another important question. 
More backends are more functions to test, so it's reasonable to add 
backends only when they're needed. I may avoid programming in language X 
from some months so no reason to keep that backed on, but when I start 
editing a file in that language, the major mode loads and so should the 
backend.

> If there is a next backend which indicates the same root, why do we 
> need the first one? 
We don't know what the next backend in line indicates. Nor do we care 
about it since the current one already gives us something. We just try 
to find backends until we find one in the order of priority and then stop.

> Suppose I call project-find-file, meaning to jump to another file in 
> the same Git repository. And instead I am shown only a list of files 
> in the current subdirectory because it contains, say, a Makefile. Is 
> that a good idea to enact this kind of behavior automatically? 
If a user believes that it looks like a duck, it should squeak like one. 
Sure you personally may want to suppress some possible project backends 
from firing, but someone may want the opposite.

I want to remind you of this recent-ish thread on HGE:

https://lists.gnu.org/archive/html/help-gnu-emacs/2021-09/msg00045.html

Lets take the maven example presented there. We have a project 
containing modules. The user wants to compile both independently. We can 
write two different compilation commands, one that works on the project 
and one that works on the module. Or we can just have a single command, 
since the compilation process is not different in any way for both. Then 
we can give that command some prefix that would make it work not on the 
project itself but on the root project of that project.

The Makefile example is your strongest argument here, but we can define 
find functions for it recursively. That is until you find a Makefile 
that does not have a dominating Makefile of it's own. And if all else 
fails you can just use the proposed plain project mark.

> What user-level commands are going to benefit from this setup?
It seems that we somewhat differ in our priorities for project 
treatment. You seem to prioritize the logical grouping of files for 
editing operations, while I prioritize "actionability". If a certain 
directory has a set of unique actions that can be performed on it, then 
it's a project for me. And while your observation that such emphasis on 
actionability may result in worse logical grouping is broadly true, it 
is not necessarily true that a blind reliance on VC backend would result 
in proper logical grouping. Sure, that would be true for most projects, 
but oftentimes you have multiple independent, but related projects 
sharing the same repository.