[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: Eglot, project.el, and python virtual environments
Date: Sat, 19 Nov 2022 03:12:21 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]