3 ms·

Stupid question: who controls the language server? If I have multiple projects or multiple branches of one project or even just multiple build folders for diffe

Stupid question: who controls the language server? If I have multiple projects or multiple branches of one project or even just multiple build folders for different configurations, how do I tell the language server what I am currently working on? If I put the setup in my home directory, I am limited to a single setup (compiler, stdlib). If I put it into the project directory, I am limited to a single build for, and potentially a single branch, and I will have multiple instances of the lsp running if I stop working on one project. If I put it into the build for, which seems sensible, how does the editor decide which server to run or ask? It seems to me that I need some sort of project manager that acts like a lap proxy and then resolves these issues. Do I need to write one myself?

gkfasdfasdf 6y ago
Not a stupid question! The editor/plugin manages the language server process, and starts it as necessary with whatever project config it found for the file being edited.
mellery451 6y ago
as to how clangd sees your current translation unit, it comes down to the compile_commands.json (which is per-TU settings) or the more general compile settings in the config file(s) (https://clangd.llvm.org/config.html https://clangd.llvm.org/config.html). If you need to change your TU settings, you could have a simple scheme that symlinks compile_commands to different files depending on build type and then restart the server. I've not typically needed to do this (I tend to just stick with a debug build compile DB...), but it's something you could do pretty easily. There is one clangd process per editor process. If you have multiple projects with distinct compile_commands you might be able to come-up with a scheme to switch between DBs and relaunch clangd. Alternatively, you could try merge all compile_commands together, but I'm not sure the effort would be worth it -- just running separate vims seems like it makes the most sense to me. For switching between branches, you can typically regenerate the compile commands DB pretty easily (if you use cmake...), but it's really only necessary if there are big differences in files and/or compile settings between branches.
MrUnderhill 6y ago
I too would love a plugin for this.. I'd like to run the LSP server in a Fedora toolbox, then some sort of property in the project's compile_commands.json or .vimrc that tells it where to find the LSP server. (Fedora toolbox mounts your home directory, so paths etc shouldn't be a problem.) At the moment, I run everything (toolchain, LSP server, nvim) in a toolbox. Works well, but it feels unecessary to have a copy of vim in every container.
vyskocilm 6y ago
Well, quite irony is that the best support I ever saw was... JavaScript and Node. As every such project has node_modules with dev dependencies, so everything can use project local dependencies. Ale does that.
Asooka 6y ago
What I do currently is run an LS per repo with its configuration stored in the repo, so: + ~/repos/repoA | - CMakeLists.txt | - compile_commands.json -> ../../build/repoA_config1/compile_commands.json | + ~/build/repoA_config1 | - CMakeCache.txt | - build.ninja | - compile_commands.json | + ~/build/repoA_config2 | - CMakeCache.txt | - build.ninja | - compile_commands.json etc. for repoB, C, ... That said I'm thinking on flipping it around - keep the LS configuration in the build folder, and symlink the source folder in it. That way I can have several different configurations in effect at once and switch between them easily. Currently I have to change where compile_commands.json points to if I want to change YouCompleteMe's completions. Your editor should manage the language server and you should just have to provide the configuration it expects in the directory you start it in.

gkfasdfasdf 6y ago

Not a stupid question! The editor/plugin manages the language server process, and starts it as necessary with whatever project config it found for the file being edited.

mellery451 6y ago

as to how clangd sees your current translation unit, it comes down to the compile_commands.json (which is per-TU settings) or the more general compile settings in the config file(s) (https://clangd.llvm.org/config.html https://clangd.llvm.org/config.html). If you need to change your TU settings, you could have a simple scheme that symlinks compile_commands to different files depending on build type and then restart the server. I've not typically needed to do this (I tend to just stick with a debug build compile DB...), but it's something you could do pretty easily. There is one clangd process per editor process. If you have multiple projects with distinct compile_commands you might be able to come-up with a scheme to switch between DBs and relaunch clangd. Alternatively, you could try merge all compile_commands together, but I'm not sure the effort would be worth it -- just running separate vims seems like it makes the most sense to me. For switching between branches, you can typically regenerate the compile commands DB pretty easily (if you use cmake...), but it's really only necessary if there are big differences in files and/or compile settings between branches.

MrUnderhill 6y ago

I too would love a plugin for this.. I'd like to run the LSP server in a Fedora toolbox, then some sort of property in the project's compile_commands.json or .vimrc that tells it where to find the LSP server. (Fedora toolbox mounts your home directory, so paths etc shouldn't be a problem.) At the moment, I run everything (toolchain, LSP server, nvim) in a toolbox. Works well, but it feels unecessary to have a copy of vim in every container.

vyskocilm 6y ago

Well, quite irony is that the best support I ever saw was... JavaScript and Node. As every such project has node_modules with dev dependencies, so everything can use project local dependencies. Ale does that.

Asooka 6y ago

What I do currently is run an LS per repo with its configuration stored in the repo, so: + ~/repos/repoA | - CMakeLists.txt | - compile_commands.json -> ../../build/repoA_config1/compile_commands.json | + ~/build/repoA_config1 | - CMakeCache.txt | - build.ninja | - compile_commands.json | + ~/build/repoA_config2 | - CMakeCache.txt | - build.ninja | - compile_commands.json etc. for repoB, C, ... That said I'm thinking on flipping it around - keep the LS configuration in the build folder, and symlink the source folder in it. That way I can have several different configurations in effect at once and switch between them easily. Currently I have to change where compile_commands.json points to if I want to change YouCompleteMe's completions. Your editor should manage the language server and you should just have to provide the configuration it expects in the directory you start it in.