emacs-lsp
server process spawned on home not project root
testing with clojure-lsp, it seems that the process is being sapwned from my home dir and not the project root, this probably shows a bug on server side, but other servers may rely on the same
I think I encountered the same with rust-analyzer, but to be sure to repro I'll need to make sure that I can log the folder that's been chosen, I just assumed I had weird Doom shenanigans, and it might still be the case tbh
In upstream Emacs, the process is spawned in default-directory as working dir ? Is that what we need to check for the fork?
I think so @gagbo , I made a commit on clojure-lsp fixing this on server side, but it'd be nice to follow same emacs standard to avoid issues indeed
I am experiencing something that seems like it may be related. The error message I'm seeing with rust-analyzer is,
LSP :: rust-analyzer failed to load workspace: "cargo" "--version" failed: No such file or directory (os error 2)
I use direnv to setup development environments, and it seems like emacs-lsp is finding rust-analyzer (which is supplied by direnv in the project directory), but then starting rust-analyzer itself in the wrong directory.
os error 2 is "file not found", and given that the command that errored is cargo --version, I suspect that your setup doesn't give a path where cargo is found by Emacs, rather than rust-analyzer
Yes, but emacs is finding rust-analyzer which is only available with direnv in the project directory (rust-analyzer and cargo are provisioned via nix). So somehow the server initialization is getting started in the right directory with the right PATH, and is then going wrong.
I have no such issues with the main branch of emacs.
I think it is caused by the fact that we don't propagate the emacs env. Which ATM is kind of expected with the code as it is.
Yes, I thought it was interesting how clearly the error message suggested that given the direnv interaction. Is the needed change to fill out the SSP_Opts value in json-rpc-connection?
Is there any temporary/easy workaround for this? My setup is the same as @acowley with direnv, so I'd need env to be propagated.
I'm probably facing the same issue with lean4, the server complains about unknown project files/modules as if it was spawned in the same directory as the emacs process (instead of default-directory). One simple workaround is to start the emacs process in the project directory itself, the server works perfectly in this setting but it has the caveat I need one emacs process per project. The issue is not present in upstream emacs.
