Hacker News Reader

Comment by choeger | Hacker News Reader

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?

View on HN

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.

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.

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). 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.

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.

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.

Reply on news.ycombinator.com