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

["João Távora" <joaotavora@gmail.com>]

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

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

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

João