On Fri, 11 Nov 2022 at 04:45, João Távora <joaotavora@gmail.com> wrote: > eglot-server-programs grew formidably over the last 4 years, and I have > no objections to keep growing it. Being exhaustive is going to be > reasonably hard, because so many servers will continue to appear. Even > faster than programming languages. And some servers are just abandoned, > which is another annoyance. And we should not assume the user won't > want to tweak to add flags or servers we don't know about. That would > contradicts my lengthy experience with the uses of this variable. I might be using Eglot unconventionally, but this is how I do it: There are multiple projects, with their specific compiler versions and library dependencies. If I installed all of that directly on my machine, Iâd have version hell. Therefore, for each project, I build a docker image with all the external dependencies packed in. I mount my source tree into a container and invoke the build in it. Emacs, on the other hand, runs on the host machine. Thus, my compile-command is defined in .dir-locals.el and starts with âdocker run --rmâ. Similarly, I put the language server(s) into the same container image. This way, it has access to external library sources. So, my eglot-server-programs is overridden in each project to run a script that starts e.g. clangd in a container spun up from the project-specific development tools image. I do not bother writing out a copy of the full default value of eglot-server-programs with my dockerized server substituted or prepended. The expectation is that each project only uses one or no more than a handful of language servers.
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