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

[Nikolay Kudryavtsev]

> 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.