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

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

[-- Attachment #1: Type: text/plain, Size: 6336 bytes --]

> When should we not do it? 
Personal preference. I'd probably never hide subproject files in 99% of 
the projects I work on.

> But then you will end up specifying the same information twice. Once 
> when setting up those new backends -- and the second time when 
> configuring the parent project to ignore particular subdirectories.
You can have a `project-hide-nested-project-files' variable, set it once 
for all backends. Maybe per backend version too. For me personally, if I 
ever were to hide subproject files it would be on a rare project and it 
would be on the same backend, in which I would normally never hide them, 
so for my workflow this is a per project setting only.

> why not have a single backend for that purpose, with a custom var 
> containing the list of files names?
Right, so remember, I said we can use this to realize most of the 
Projectile backends? Well, the ones we can't realize would require 
regexps, usually of the "\\.ext$" kind. So you have to account for those 
too. Then there may be some other possible cases requiring custom function.

So we have at least two reasons to prefer adding actual separate 
backends over one catch-all filename based. Orderability and 
customizability.

Lets say I have this structure: VC root, subfolders containing multiple 
related, but independent projects in some programming language, backend 
for which exists; deeper in one of the subfolders I have a GTAGS file, 
assume GTAGS backend exists in one form or another. GTAGS file is placed 
in this location because elsewhere in the repo there are symbol names 
that are too close to each other and it's more convenient not having 
them show up when I lookup something. I don't want VC backend to define 
the project root here for obvious reasons. The major mode build tool 
backend should do OK and I may or may not want GTAGS to define the 
project root.

Having one find-function list which the user can reorder as he sees fit 
and that list may contain not just filenames, but regexps and custom 
functions too.

As for customizability: we're already discussing at least 2 backend 
settings: hide-nested-project-files and recursivity. Those settings 
require a backend to be something more than a filename string in a 
secondary list.

> That didn't really answer my question. 
All right, lets rephrase the answer. At the moment in time a backend is 
defined we do not know every single exact situation that backend would 
have to operate in, because that would require the ability to predict 
time, which we technologically do not have at the current moment. Lets 
say I add a backend for my major mode. Someone in exactly 18 days, 6 
hours, 5 minutes and 3 seconds decides to use it to work on his project. 
Unfortunately I do not know whether his project is in VCd and if VC 
project backend returns the same root. If I could predict time and my 
prediction of all possible future use cases would show that VC backend 
returns the same root for every single one of them, I of course would 
not bother adding mine. But because my imperfect human understanding 
makes me think that it won't, I have to add a backend of my own.

> I'm not sure how I would suppress "possible project backends" from 
> firing. 
Since you believe that VC backend gives you the best result, you can 
always ensure on your end that you never get, say a Makefile backend in 
your project-find-functions.

Probably the best route here globally, is changing 
project-find-functions to a list with numerical priorities, so that you 
could set VC backend to priority 0 in your init and instruct mode 
developers to never put anything with the same priority or higher in the 
docstring.

> That's possible, but it's not at all a guarantee that in every big 
> project every Makefile will have a "dominating" Makefile of its own. 
Yes, but we can define a list of possible parent backends for every 
backend. For example you could set VC as possible parent backend for 
Makefile. Would probably not be a good idea in general, but for your 
VC-first workflow, should be fine.

> It would seem like your vision of the project could benefit from a 
> notion like "facet". E.g. a project lookup would search for not just 
> "the current project", but "the current build project" or "current 
> file listing project", or... I don't know what else, actually. But I'm 
> sure there can be other additions (something test-framework related, 
> maybe). 
Or a "module" right? I was thinking about this too, and could not find a 
good name for it either. Such a solution would be a reliable working 
compromise between our schools of thought. You get your project-root 
untouched, I get my own project root to do whatever I please with it. 
The problem with it is that it's really overengineered. For most 
projects there would be a 1 to 1 relationship between the project and 
the module(artifact?) and even if it's not 1 to 1, there's a root module 
most of the time. That's why it feels inferior to me in comparison to 
just treating everything as projects and going bottom up.

> Which would return, for example, new kind of object, and that object 
> could tell the parent directory of its build file, and the list of the 
> tasks described in it, and... perhaps something about how those tasks 
> should be invoked. That new abstraction could be used by commands that 
> want to interact with build files in an abstract fashion and to launch 
> build tasks. 
After studying Projectile build commands I found them inadequate, since 
it provides just two, compile and build, while even my simple major mode 
requires a separate debugging command too. This solution suffers from 
the same lack of flexibility. Take for example unit testing. It's not 
necessarily build tool subservient and can be independent from it, but 
it is situated in relation to the build tool root. The maven hierarchy 
is problematic for this too, while my "treat everything as projects" 
paradigm has an elegant solution in which you can use a numerical prefix 
to launch a build command on the Nth parent of the current project.

> There are two patches in this bug report. Have you looked at the other 
> one?
You mean the original patch? Well it is IMHO better than yours since 
it's less ambitious and does not go in what I believe to be the wrong 
direction.


[-- Attachment #2: Type: text/html, Size: 7783 bytes --]