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

[Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>]

> Available how? Through a certain keymap, or a specially named set of 
> commands? These issues matter. 
Available through a function project-current-vc. On top of that you can 
implement (global, per backend, per project) setting 
project-honour-vc-ignores. Then project-vc-* utility functions.

> If you don't care about the defaults, why argue on this bug tracker at 
> all?
Because when you're discussing multiple complicated interconnected 
issues, it's nice to spot one you don't have to discuss.

> But it's not reduced: quite the opposite, whatever the user adds (to 
> the beginning of the list) takes up a significant responsibility.
It is relegated to the second class citizenship. Remember, here I was 
talking about your patch in particular. It puts file marker backends 
into a separate list, not the generic case of users adding new backends.

> It's not the only possible solution to the problem, but I have yet to 
> see a complete design of some alternative being presented.
I've already presented what I'm proposing in previous emails:

(register-project-backend "project.file" priority 
:optimizes-file-listing nil :honuor-vc-ignores t)

Instead of adding any separate lists the same marker find functionality 
can be implemented in a backend registration function and this would 
allow people needing file marker backends to implement them on the fly, 
whenever they need one. Also it's not touching the defaults in any way, 
leaving the decision about the backend priority to the user.

> For instance, Maven modules can be reliably discovered from the parent 
> project's root directory, unlike the potential discovery logic for 
> arbitrarily nested projects (which seems like it will require a costly 
> directory tree walk). 
Yes. At the basic level it's a directory tree walk. But that's not a 
drawback of my particular proposal, since any attempt to implement the 
project unit functionality would suffer from this, regardless of the 
design chosen. You can implement any discovery strategy with any design.

> It was just an example for what a "build tool API" could look like. If 
> you know better, try to propose a different one. 
I've already proposed one. Each project backend has a set of actions. An 
action is just a function. Since most would probably be simple shell 
commands in the project-root, some easier way to define those should 
implemented. You can see whichever actions are available in some 
interactive dispatch function or the menu. Actions can be grouped into 
action groups. This is better in my opinion due to not presuming 
anything, so if you need to group by a build tool or by multiple, you 
can, but you don't have to.

> I meant a separate set of commands which would apply VCS's ignores to 
> the project operations, which the "current" VC-unrelated backend 
> apparently might not do, according to how I understood your explanations.
That would a bit clunky. Just honoring VC ignores by default is much 
better, with an option to do the opposite.

> Treating Maven modules as separate sub-projects *might* fit well with 
> that as well. 
If you can act on parent and child projects of the current, there's even 
less of a point to implement project units as a separate semantic 
unit(concept) from the project itself.