search

emacs-lsp / emacs

Mirror of GNU Emacs
http://www.gnu.org/software/emacs/
GNU General Public License v3.0
71 stars 8 forks source link

server process spawned on home not project root #5

Open ericdallo opened 1 year ago

ericdallo commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

andresilva commented 1 year ago

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.

luavreis commented 1 year ago

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.