On 2022-11-18 11:21, Tim Cross wrote:
Is this something which should be addressed at the eglot level or at theproject level? It seems to me that what you really have here is a main project which consists of a number of sub-projects and that it could be beneficial more generally if you could more easily isolate out the sub-projects (not just for eglot, but possibly for other tools as well)at the project.el layer rather than the eglot layer. This could mean theuser has to be more involved in defining the project and sub-project structure/relationships, but that may be reasonable when you have more complex project structure? 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.
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