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

[Dmitry Gutov <dgutov@yandex.ru>]

On 20.11.2022 03:51, João Távora wrote:
> Danny Freeman <danny@dfreeman.email> writes:
> 
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>
>>> Then your solution should work okay, but it also means it belongs to the category of Eglot hacks (as
>>> opposed to project.el hacks).
>>
>> It is absolutely an Eglot hack :)
> 
> I don't consider this a hack at all.  Not only does it work okay, it's
> how supposed to work.

It's a hack because it's a common case which every affected user ends up 
fixing through editing their init file.

> Most of the time, the default project-finding methods bundled with Emacs
> work extremely well, in fact so well that it seems almost offensive when
> they don't.  But it's crucial to recognize that this is not just because
> of LSP reasons.  For example, simply because of the relatively poor
> performance of the default project.el VC backend in a gargantuan repo of
> 400k files, I've had to define a different notion of "project" recently.

Or the OS used, with its different performance characteristics. And the 
performance of the W32 Emacs port as well. Anyway, this is beside the 
point, since we'll always want more improvements to performance, of 
course, to be able to handle larger projects on slower systems.

> What constitutes a useful "project" for a user's setup can indeed vary
> immensely.  So project.el should grow to address these corner cases,
> maybe inventing new abstractions not tied to a particular client,
> including LSP.  Maybe both this Python venv example and my "gargantuan
> repo" example are hinting at possible uses for a "subproject"
> abstraction?  Just food for thought.

If you want more food for thought, look up my previous messages in this 
thread regarding "subprojects". And others' too.

In this thread people are asking for a change in Eglot's behavior, and 
not in project-related commands. For example, to keep 
'project-find-file' listing all files in the parent project, not just in 
the current subproject.