server process spawned on home not project root

[ericdallo]

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

[gagbo]

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?

[ericdallo]

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

[acowley]

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.

[gagbo]

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

[acowley]

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.

[yyoncho]

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.

[acowley]

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?

[yyoncho]

If you mean envp in SSP_Opts - I believe the answer is yes.

[andresilva]

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.

[sophicshift]

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.