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

[Dmitry Gutov]

On 18.11.2022 09:43, Eli Zaretskii wrote:
> Another evidence that this should be solved in Eglot is that "the
> other LSP mode" doesn't depend on project for this.

FWIW, "the other LSP mode" just provides more choices for the user in 
general, which is in line with its overall design.

> I would also like to hear from Dmitry what are his thoughts on this.

That's my inclination as well, based on the requested behavior in this 
thread.

We do have an old feature request in bug#54228 (which I'm hoping to 
resolve soon enough; more voices in that discussion would be welcome, by 
the way), but it can only be an answer here if people are okay with the 
"subprojects" behaving like separate projects altogether (meaning, for 
example, that project-find-file only offers files from the current 
subproject to jump).

Or else, we'd have a new notion of subprojects, and a separate set of 
commands to navigate/search/replace/etc in such. Not sure if that's what 
people want either.

And if not (to both), the proposed fixes using project-find-functions 
are not a good fit too.

Then I suppose Eglot could just learn a set of markers of its own (e.g. 
files named .eglot and/or build file names of popular tools). Not sure 
if LSP recommends something in that regard, or just defers to the 
editors. I wonder how VS Code and NeoVim, etc, make this decision.