[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: Tue, 22 Nov 2022 17:48:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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.

reply via email to

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