> Date: Fri, 18 Nov 2022 15:38:34 +1300 > From: Phil Sainty <psainty@orcon.net.nz> > Cc: emacs-devel@gnu.org > > > I guess my question here is whether the focus should be on enhancing > > project.el rather than modifying/enhancing eglot.el to handle this use > > case? > > It seems to me that while project.el could acquire the notion of > sub-projects, the *meaning* of a sub-project would be entirely > specific to the tool which needed it (eglot in this case). And if you > had multiple tools which each wanted some kind of sub-project, you > might find that some of the sub-projects were overlapping others, > depending on the needs of the tools which each one was related to. > > Still, if eglot could ask project.el for "the nearest sub-project > defined for 'eglot' usage, if any, and otherwise the main project" and > project.el had been told that for the project at /path/to/proj there > was an 'eglot' sub-project at /path/to/proj/subdir/foo, then that > could be useful. > > So project.el could provide an API for defining and returning > sub-projects, but it would be up to eglot (or other tools) to cause > such sub-projects to have any kind of effect, and it would be up to > the end-user to define their 'eglot' sub-projects in the first place. 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 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. Another evidence that this should be solved in Eglot is that "the other LSP mode" doesn't depend on project for this. I would also like to hear from Dmitry what are his thoughts on this.
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