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

[Dmitry Gutov]

On 21/11/22 15:45, João Távora wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > On 20.11.2022 22:35, João Távora wrote:
> > > 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.
> >
> > No, I'm saying performance itself shouldn't sway the decision in this
> > case one way or another.
>
> I think I couldn't disagree more.  If there something that should
> influence system design (usually as early as possible) are performance
> considerations: they can't be an afterthought. That said, looking
> forward to these "other means".

Performance is important, but desired behavior comes first.

> > > 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.
> >
> > Perhaps in your particular project it makes sense. Most of the users I
> > see in this thread seem to prefer it otherwise in their projects.
> >
> > So that seems to indicate that the Eglot fix and the subprojects thing
> > should be separate, implemented without tying one to the other.
>
> Certainly shouldn't be "tied" to the other, but if subproject
> configuration becomes available in project.el, Eglot can easily take
> advantage of it (perhaps even automatically).

I cannot reasonably add a feature with only one known (and expected) 
consumer. Whether we call it subprojects, or an eglot-only backend, or etc.

FWIW, "subprojects" that I can imagine would probably be implemented as 
a new hook or a list of "project markers". As long as only Eglot uses 
it, it might as well live there.

> As the Eglot "fix" for the current status quo, it's just a
> documentation change to the manual.

I think it's a problem when a significant part of userbase need to make 
a change to their config (a specific, non-trivial one) to make Eglot 
functional in their projects.

I sympathize with not wanting to collect that info for every file type 
and their dog in Eglot, but it's not 100% obvious to me that the place 
for that info is in major modes.