Open fxfactorial opened 2 years ago
the remote machine's .bashrc uses gimme for golang,
export GOPATH="$HOME/go" export PATH="$GOPATH/bin:$PATH:$HOME/bin:/usr/local/cuda-11.4/bin" export GO111MODULE=on source ~/.gimme/envs/go1.17.5.env 2>/dev/null
I don't think that any of these is picked by tramp. If these are esential for starting gopls, create a wrapper script that sets them and starts gopls. Note that if the binary that you have provided to lsp-mode is crashing there is nothing lsp-mode can do.
@yyoncho right, that's why i added
(add-to-list 'tramp-remote-path "/home/mev/.gimme/versions/go1.17.5.linux.amd64/bin")
(add-to-list 'tramp-remote-path 'tramp-default-remote-path)
(add-to-list 'tramp-remote-path 'tramp-own-remote-path)
and
LSP :: Connected to [gopls-remote:3211248/starting].
seemed to imply that the binary indeed started up
EDIT: I copied the gopls binary to under /usr/local/bin and /usr/bin, same error so i dont think its because the binary not seen and the lsp-log buffer does say
Command "gopls" is present on the path.
Check stderr which will be in /tmp on the remote machine. Also, you may try to start gopls in eshell buffer to check what the error is.
@yyoncho right, that's why i added
I meant that things like export GO111MODULE=on
won't be in gopls env.
thank you, checked /tmp and found the gopls-remote-n-stdeer, it always says
gopls: unmarshaling jsonrpc message: unexpected end of JSON input
Most likely this: https://github.com/emacs-lsp/lsp-mode/issues/2375 . There are several attempts to fix this
gotcha - so the input is too large wrt the time to complete available for the async read?
thank you for the quick replies
Tramp for some reason(unknown to me) converts \n
in \r\n
. The result is that the message end is confused and json parsing fails. There are PRs claiming to fix that. I haven't had the time to investigate and merge the fix(FTR on my side I am unable to hit the issue using docker images).
Thank you for the bug report
lsp-mode
related packages.M-x lsp-start-plain
Bug description
Trying to get golang coding over tramp working and running into issues
in Messages , I have
which seems to imply that gopls-remote is working correctly but then it explodes on a missing go.mod
the remote machine's .bashrc uses gimme for golang,
and my ( i think only relevant parts) of emacs init.el
appreciate any insight, help
Steps to reproduce
wrote the config code used
Expected behavior
should not crash exit 2
Which Language Server did you use?
gopls with lsp
OS
Linux
Error callstack
No response
Anything else?
No response