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

["João Távora" <joaotavora@gmail.com>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 22/11/22 23:34, João Távora wrote:
>> Given a tree a tree structure such as a file system that can have
>> very many nodes, not having any means to take advantage of that structure
>> tree-ness (as project.el clearly doesn't: see the protocol of
>> project-files and
>> the lack of sub-projects) is going to be a hard limitation.  Monorepos
>> are really popular in many businesses and many of these are large and/or
>> getting larger.
>
> Like I said: if you want sub-projects, go and write a proper feature
> request, with expected behavior, which commands are affected, which
> are not.

I've just described in the other thread that I would like to have
finding references and finding files to be able to operate on either
sub-projects or super-projects on demand.  This is the problem I'm
facing, and it's not new.  For example, there is only: find file in the
very large project, and find file in the current directory.  There is no
"find file in this section of the repo, which is a sub-project in
itself".

IMO, it's not "improper" to describe problems and use cases: in fact I
prefer that people describe over jumping to vapourware solutions.  But
if you're really looking for a suggestion as to _how_ to design it, I
suppose my problem would be well dealt with a negative prefix on C-x p g
and C-x p f giving me a choice of which project to operate on.  But that
is only one possibility: new commands are also acceptable.

As to how one defines sub-projects, I think having
project-find-functions be used to compose a list of projects (as opposed
to to stopping after finding one) would be a nice way.  It would be nice
if the elements of project-find-functions could be informed of the
projects found so far.  But keeping the "stop after first" behaviour and
having members return a more complex object is maybe also good.  I
really don't care much what you eventually choose, as long as I can
solve my problem.

> It seems obvious to me from this thread that a lot of people don't
> actually want sub-projects as a separate entity (based on the
> requested behavior, hi Stefan!), they just want Eglot to work with the
> structure of their project.

The current Eglot solution to start servers in sub-directories of
repositories has already been described (and apparently accepted).

João