Re: Eglot, project.el, and python virtual environments

[Dmitry Gutov]

On 21/11/22 22:58, Augusto Stoffel wrote:
> On Sun, 20 Nov 2022 at 17:36, Dmitry Gutov wrote:
>
> > If you want more food for thought, look up my previous messages in
> > this thread regarding "subprojects". And others' too.
> How about the much simpler situation where you want a subdirectory of a
> Git repo to count as its own project, completely disregarding any other
> directories?
>
> I guess it would be nice to support this by just creating a special
> marker file, but I couldn't figure out if it's supported.

It's a seemingly simple issue which becomes hard once you want to create 
a turnkey solution for everybody which is simultaneously fast, easy to 
use and still flexible. Or at least for me it did.

There are a couple of patches I put up for discussion in 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#82, but alas the 
discussion that arose went into some other direction.

In short, the issues are:

- Whether we need to be able to exclude the subprojects from 
project-files of the parent project. Can be useful with large projects; 
not so easy to do if the subprojects are defined by some file markers 
down in the directory tree.

- If we don't, I guess nobody needs the defcustom 
'project-vc-merge-submodules' either?

- Or if we do, would it be okay to recommend the user customizes the 
ignores of the parent project manually to exclude the specific 
subprojects? In addition to setting up the markers. And this way we lose 
the potential ability to add their dirs to project-files of the parent, 
to make them more easy to reach (project-vc currently does that with 
project-vc-merge-submodules=nil), or list them through a separate 
command, etc.

- Would markers be limited to file names (perhaps with wilcards)? If so, 
it might be feasible after all to exclude marker-based subprojects if 
the user so wishes using an extra 'git ls-files -co -- ...' call. It's 
not free, though.

- Should subprojects obey "ignores" of the parent project? If they do 
(which would make sense in practice -- obeying .gitignore of the repo), 
how do we describe that semantically if a subproject is a separate 
project type/backend?

Anyway, I suggest you give the original messages a read (#82 and #83, at 
least) and let me know what you think. Preferably in the bug comments, 
since those will be easier to find later.