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

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

So is every use of add-hook, for that matter.  Emacs has an init file
because it's not Microsoft Word.  The code you're describing is exactly
why I added the variable and how I intended it to work when I added 1.5
years ago.  That's as far as I'll wade into puerile arguments over
who/what is a "hack".

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

You shouldn't be writing performance off as a detail.  You can't just
wish it away, or think users will change OSs soon.  You should instead
think of solutions that help manage size and complexity.

But it's not just performance.  For example, in this particular project,
it makes sense, by default, to grep the superproject, but C-x f in the
subprojects.  Lack of subproject support in project.el means I have to
work around this with defadvice.

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

What about them?  I've said all I wanted to say on the matter.  If you
to make some specific point, make a specific point.

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

People report problem they are facing.  They are free to suggest a real
or vapourware design to fix them.  My task, as Eglot maintainer, is to
understand the problems, consider the suggestions, and often point
people to real existing solutions.  In this case, Danny figured out
exactly how it's supposed to work from the docstrings of
eglot-lsp-context and eglot--current-project.  All that's needed is to
document it in the manual.  Alternatively, I've suggested that Danny's
code be added to python.el, so that the user need not change init files.

And you're of course free to make some egloss.el library that requires
eglot.el and has all the LSP paraphernalia you think is missing from
Eglot (maybe you'll end up with lsp-mode, who knows?).  But I think
better tools for configuring very large projects with of shapes and
sizes should be in the project management library of Emacs, which is
project.el.  menawhile, we have the real solutions described above.

João