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

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

Danny Freeman <danny@dfreeman.email> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> Then your solution should work okay, but it also means it belongs to the category of Eglot hacks (as
>> opposed to project.el hacks).
>
> It is absolutely an Eglot hack :)

I don't consider this a hack at all.  Not only does it work okay, it's
how supposed to work.

Dmitry has often suggested an Eglot-specific project.el backend, i.e. a
new type of object to specialize project.el generic functions to, but I
think that a good idea: Eglot is not a source of truth for project
information, like .git directories.  Instead Eglot is a _client_ for
that information as gathered from via some arbitrary method that Eglot
is angnostic to.  

The information is forwarded to the LSP server as the "workspace", but
the user needn't ever hear that M$ lingo.  So I don't think we should
invent an second notion of "LSP Workspace" into Emacs via Eglot.
Personally, when I tried lsp-mode a long time ago, "workspaces" was a
confusing concept and useless to me as a user.  Emacs users should just
think of "projects".

Most of the time, the default project-finding methods bundled with Emacs
work extremely well, in fact so well that it seems almost offensive when
they don't.  But it's crucial to recognize that this is not just because
of LSP reasons.  For example, simply because of the relatively poor
performance of the default project.el VC backend in a gargantuan repo of
400k files, I've had to define a different notion of "project" recently.

What constitutes a useful "project" for a user's setup can indeed vary
immensely.  So project.el should grow to address these corner cases,
maybe inventing new abstractions not tied to a particular client,
including LSP.  Maybe both this Python venv example and my "gargantuan
repo" example are hinting at possible uses for a "subproject"
abstraction?  Just food for thought.

> (defun eglot--find-lsp-root (dir)
>   (when-let ((root (and eglot-root-marker
>                         eglot-lsp-context
>                         (locate-dominating-file dir eglot-root-marker))))
>     (cons 'transient root)))
>
> (add-hook 'project-find-functions #'eglot--find-lsp-root)


I think the code above is fine, but it belongs in the user's
configuration.  In fact, it belongs in the manual, in a section similar
to what used to be section called "Handling Quirkly Servers" in the old
README.

This code doesn't belong in Eglot.  Eglot is designed as thin layer
making different Emacs facilities communicate with LSP servers.  Eglot's
user interaction is mostly for LSP basics such as connect/disconnect and
Eglot's user preferences deal with LSP in its generality.  Baking
project definition facilities into Eglot would bloat it and I don't want
that.

Are we worried that users will find it hard to apply snippets such as
Danny's?  My experience with libraries such as Yasnippet, SLY and Eglot
tells me otherwise: if robust simple Lisp snippets such as the one above
are easy to find, users have no trouble applying them.  But if we really
must have a point-and-click interactive interface for programming-averse
programmers :-) , then we can also remember that Eglot is also an
Elisp-level API for major-modes to take advantage of.

... Which means that if the problem here is both LSP and Python-specific
a .venv specific version of the above snippet could well live in
python.el.

Here, and in other cases such as complicated definitions of
eglot-server-programs, or making use of server-specific LSP methods,
there is no reason why a major-mode shouldn't (require 'eglot).

João