From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Danny Freeman <danny@dfreeman.email>
Cc: "Eli Zaretskii" <eliz@gnu.org>,
"Phil Sainty" <psainty@orcon.net.nz>,
"Dmitry Gutov" <dgutov@yandex.ru>,
theophilusx@gmail.com, emacs-devel@gnu.org,
"João Távora" <joaotavora@gmail.com>
Subject: Re: Eglot, project.el, and python virtual environments
Date: Fri, 18 Nov 2022 11:36:22 -0800 [thread overview]
Message-ID: <874juwvyvd.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <87k03swcye.fsf@dfreeman.email> (Danny Freeman's message of "Fri, 18 Nov 2022 08:55:35 -0500")
Danny Freeman <danny@dfreeman.email> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I think this turns the table for no good reason. I see no reason to
>> add complex new abstractions to project.el just because we have an
>> issue with configuring Eglot in the use case presented in this thread.
>>
>> Let me remind you that Eglot already supports a kind of "sub-project":
>> it uses the same LSP server only for those source files in a project
>> that share the same major mode. So parts of a project that use a
>> different PL are already considered to be a "sub-project", and Eglot
>> does that without any help from project.el.
>>
>> Given that this feature already exists, a proposal to add a
>> "sub-project" notion to project.el should describe at least several
>> use cases of such "sub-projects" where the separate "sub-projects"
>> share the same programming language. If the situation with python-env
>> is the only one we find reasonable, IMO adding "sub-projects" to
>> project.el is an unjustified complication.
>
> I think that most monorepo projects fall into this category. That is a
> large version controlled repository with multiple sub projects in it.
> Sometimes the subprojects are written in different languages. Usually
> there are sub folders of the monorepo project that act as sub projects.
> I ran into one at work yesterday, but I'm not sure what I would have
> project.el do differently there. I preferred it's behavior actually.
>
>> I suggest to look at this as an Eglot issue, not a project.el issue.
>> What is requested here is an ability to tell Eglot which directories
>> should share the same LSP server and which ones should have separate
>> servers. It shouldn't be hard to have a buffer-local variable to tell
>> Eglot that, or a function that accepts a buffer and returns a value
>> that Eglot can use for this decision. All we need is a way to tell
>> Eglot which directories to communicate to the LSP server as those
>> which it should watch, and when to start another instance of the LSP
>> server even though one is already up and running for this project and
>> major mode. Let's not complicate project.el for a problem that
>> doesn't belong to it.
>
> Is this not exactly what `eglot-lsp-context` is for? Using my example
> from earlier in the thread is what I suspect is the "right way" to solve
> this:
>
> ```
> (defun project-find-virtualenv-for-eglot (dir)
> (when eglot-lsp-context
> (let ((root (locate-dominating-file dir ".virtualenv")))
> (when root
> (cons 'transient root)))))
>
> (add-hook 'project-find-functions #'project-find-virtualenv-for-eglot)
> ```
>
> It can be made more targeted by checking the value of directory if
> necessary. (I could also a use when-let)
>
> It is an obscure way to solve this problem. I only know about it from my
> time spent with eglot's source. Not every user will have that
> experience. How could we make that better?
I agree that this seems like the most likely point of customization --
and also agree that if this approach gets "blessed" somehow it could
probably be made more obvious, if only through documentation.
I wonder if the same entry point could be used for language server
short-circuiting: for instance, the transient project structure could
contain a sexp that's used to mask the value of `eglot-server-programs',
to point Eglot at different programs. It looks like that value would get
cached for later use.
Anyway, I haven't looked at Eglot closely enough to suggest anything
more than that. I'll try to read through the library this weekend.
Eric
next prev parent reply other threads:[~2022-11-18 19:36 UTC|newest]
Thread overview: 139+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-16 18:37 Eglot, project.el, and python virtual environments Eric Abrahamsen
2022-11-16 22:24 ` Danny Freeman
2022-11-16 22:53 ` Eric Abrahamsen
2022-11-17 13:41 ` Danny Freeman
2022-11-17 18:06 ` Eric Abrahamsen
2022-11-17 18:48 ` Yuan Fu
2022-11-17 22:21 ` Tim Cross
2022-11-18 2:38 ` Phil Sainty
2022-11-18 7:43 ` Eli Zaretskii
2022-11-18 13:55 ` Danny Freeman
2022-11-18 15:22 ` Eli Zaretskii
2022-11-18 15:53 ` Danny Freeman
2022-11-18 19:36 ` Eric Abrahamsen [this message]
2022-11-18 15:06 ` Stefan Monnier
2022-11-18 15:17 ` Eli Zaretskii
2022-11-18 15:28 ` Stefan Monnier
2022-11-19 1:12 ` Dmitry Gutov
2022-11-19 7:42 ` Eli Zaretskii
2022-11-19 13:06 ` Dmitry Gutov
2022-11-19 13:14 ` Eli Zaretskii
2022-11-18 18:31 ` João Távora
2022-11-19 1:13 ` Dmitry Gutov
2022-11-19 1:56 ` João Távora
2022-11-19 15:23 ` Dmitry Gutov
2022-11-19 19:17 ` Danny Freeman
2022-11-19 19:49 ` Dmitry Gutov
2022-11-19 21:22 ` Danny Freeman
2022-11-20 1:51 ` João Távora
2022-11-20 15:36 ` Dmitry Gutov
2022-11-20 20:35 ` João Távora
2022-11-20 22:05 ` Dmitry Gutov
2022-11-21 13:45 ` João Távora
2022-11-22 15:48 ` Dmitry Gutov
2022-11-22 21:12 ` Stefan Monnier
2022-11-22 21:34 ` João Távora
2022-11-22 22:00 ` Dmitry Gutov
2022-11-22 23:23 ` João Távora
2022-11-23 0:03 ` Dmitry Gutov
2022-11-23 13:57 ` Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) João Távora
2022-11-23 20:33 ` João Távora
2022-11-24 2:49 ` Dmitry Gutov
2022-11-24 8:42 ` João Távora
2022-11-24 22:17 ` Dmitry Gutov
2022-11-25 19:56 ` Subprojects in project.el João Távora
2022-11-25 22:33 ` Dmitry Gutov
2022-11-26 0:00 ` João Távora
2022-11-26 1:57 ` Dmitry Gutov
2022-11-26 9:23 ` João Távora
2022-11-26 13:34 ` Dmitry Gutov
2022-11-26 19:36 ` João Távora
2022-11-26 2:01 ` Dmitry Gutov
2022-11-26 9:24 ` João Távora
2022-11-24 2:51 ` Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) Dmitry Gutov
2022-11-24 6:23 ` Eli Zaretskii
2022-11-24 9:01 ` João Távora
2022-11-24 22:11 ` Dmitry Gutov
2022-11-25 7:30 ` Eli Zaretskii
2022-11-25 17:24 ` Dmitry Gutov
2022-11-25 19:45 ` Eli Zaretskii
2022-11-25 21:57 ` Dmitry Gutov
2022-11-25 23:55 ` Subprojects in project.el João Távora
2022-11-28 0:41 ` Dmitry Gutov
2022-11-26 7:26 ` Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) Eli Zaretskii
2022-12-02 1:32 ` Dmitry Gutov
2022-12-02 14:16 ` Eli Zaretskii
2022-12-02 15:08 ` Dmitry Gutov
2022-12-02 15:37 ` Dmitry Gutov
2022-12-02 15:44 ` Subprojects in project.el Stefan Monnier
2022-12-02 23:26 ` João Távora
2022-12-06 14:36 ` Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) João Távora
2022-11-24 3:01 ` Dmitry Gutov
2022-11-24 8:50 ` João Távora
2022-11-24 22:46 ` Tim Cross
2022-11-24 23:38 ` Dmitry Gutov
2022-11-25 7:07 ` Bozhidar Batsov
2022-11-25 14:58 ` Subprojects in project.el Stefan Monnier
2022-11-25 22:29 ` Dmitry Gutov
2022-11-26 2:59 ` Stefan Monnier
2022-11-26 12:30 ` Dmitry Gutov
2022-11-26 17:32 ` Stefan Monnier
2022-11-27 0:25 ` Dmitry Gutov
2022-11-25 20:32 ` João Távora
2022-11-28 4:10 ` Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) Tim Cross
2022-11-28 17:21 ` Dmitry Gutov
2022-11-29 9:56 ` Subprojects in project.el João Távora
2022-11-29 18:40 ` Dmitry Gutov
2022-11-29 22:21 ` João Távora
2022-11-30 0:39 ` Dmitry Gutov
2022-11-30 0:54 ` João Távora
2022-11-30 0:57 ` Dmitry Gutov
2022-11-30 1:18 ` João Távora
2022-12-02 22:47 ` Richard Stallman
2022-12-02 23:46 ` Dmitry Gutov
2022-12-03 7:09 ` Eli Zaretskii
2022-11-24 22:58 ` Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) Dmitry Gutov
2022-11-25 2:38 ` Subprojects in project.el Stefan Monnier
2022-11-25 20:23 ` João Távora
2022-11-25 22:23 ` Dmitry Gutov
2022-11-25 7:42 ` Juri Linkov
2022-11-25 20:27 ` Dmitry Gutov
2022-11-25 23:47 ` João Távora
2022-11-25 23:58 ` Dmitry Gutov
2022-11-26 0:46 ` João Távora
2022-11-26 2:07 ` Dmitry Gutov
2022-11-25 20:16 ` João Távora
2022-11-25 22:44 ` Dmitry Gutov
2022-11-26 0:37 ` João Távora
2022-11-26 2:05 ` Dmitry Gutov
2022-11-26 9:42 ` João Távora
2022-11-26 12:38 ` Dmitry Gutov
2022-11-29 10:03 ` João Távora
2022-11-29 10:17 ` João Távora
2022-11-29 19:07 ` Dmitry Gutov
2022-11-29 22:52 ` João Távora
2022-11-30 1:10 ` Dmitry Gutov
2022-11-27 19:25 ` Juri Linkov
2022-11-27 21:43 ` Dmitry Gutov
2022-11-22 23:53 ` "Backend completion style" as a first-class library. Re: Eglot, project.el, and python virtual environments João Távora
2022-11-23 1:45 ` Stefan Monnier
2022-11-25 13:16 ` João Távora
2022-11-22 21:40 ` João Távora
2022-11-22 22:13 ` Dmitry Gutov
2022-11-22 23:33 ` João Távora
2022-11-21 20:58 ` Augusto Stoffel
2022-11-23 3:37 ` Dmitry Gutov
2022-11-20 16:37 ` João Távora
2022-11-21 7:54 ` Eric Abrahamsen
2022-11-21 13:36 ` João Távora
2022-11-21 15:41 ` Alfred M. Szmidt
2022-11-21 16:49 ` Eli Zaretskii
2022-11-21 16:49 ` Eric Abrahamsen
2022-11-21 20:54 ` Augusto Stoffel
2022-11-19 23:25 ` João Távora
2022-11-19 23:40 ` Dmitry Gutov
2022-11-16 23:18 ` Philip Kaludercic
2022-11-17 1:14 ` Eric Abrahamsen
2022-11-17 6:47 ` North Year
2022-11-17 18:09 ` Eric Abrahamsen
2022-11-19 22:36 ` Stephen Leake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874juwvyvd.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=danny@dfreeman.email \
--cc=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=joaotavora@gmail.com \
--cc=psainty@orcon.net.nz \
--cc=theophilusx@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.