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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4