GNU bug report logs - #59883
Eglot gopls failed to connect

Previous Next

Full log

Message #32 received at 59883 <at> debbugs.gnu.org (full text, mbox):

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: João Távora <joaotavora <at> gmail.com>,
 59883 <at> debbugs.gnu.org
Subject: Re: bug#59883: Eglot gopls failed to connect
Date: Sun, 10 Sep 2023 21:29:42 +0200

[Message part 1 (text/plain, inline)]

Stefan Kangas <stefankangas <at> gmail.com> schrieb am So., 10. Sep. 2023, 21:21:

> Johann Höchtl <johann.hoechtl <at> gmail.com> writes:
>
> > Sorry, this bug has to be re-opened. I was confident that the described
> "work-around" is
> > stable, yet it's not. Eglot was working consistently yesterday just to
> find it non-working today
> > with the same errors.
>
> Are you still seeing this?
>

No, for me it was fixed with an update to jsonrpc which was then included
into emacs 29.1.

>
> > Am So., 11. Dez. 2022 um 14:24 Uhr schrieb Johann Höchtl <
> johann.hoechtl <at> gmail.com>:
> >
> >  I found a solution. Quick: For some reason when opening a go file using
> go-mode,
> >  Emacs/eglot generates a "textDocument/didOpen" server message. Now the
> correct
> >  reaction of a LS upon such a message in a chase where the file actually
> did not change
> >  remains disputable:
> >
> >  https://github.com/golang/go/issues/50267
> >  https://github.com/neovim/neovim/issues/16623
> >
> >  However, the gopls-team considered a "chatty" behavior of the language
> server to be
> >  better anyhow. To always send diagnostics is now the default, yet not
> released as of
> >  gopls 1.10.1
> >
> >
> https://github.com/golang/tools/commit/ec743893cd01c9423aaae4513b092c4c4c06f0f4
> >
> >  https://groups.google.com/g/golang-checkins/c/tt8Ig_UsKtE
> >
> >  To use the yet unreleased feature from gopls <at> HEAD which works, follow
> >
> >
> https://github.com/golang/tools/blob/master/gopls/doc/advanced.md#unstable-versions
> >
> >
> >  This bug report may be closed, reported for reference.
> >
> >  Am So., 11. Dez. 2022 um 13:45 Uhr schrieb Johann Höchtl
> >  <johann.hoechtl <at> gmail.com>:
> >
> >  I dug deeper into the problem:
> >
> >  * When I open a very small golang-project, eglot interconnects
> correctly with gopls
> >  * When I open a larger golang-project, eglot fails to communicate with
> gopls. In fact, it
> >  fails to direct gopls to load the project as gopls stays at a very
> small memory
> >  footprint.
> >
> >  When I uninstall go-mode OR find-file-literally *.go and later enable
> eglot, gopls  is
> >  correctly "directed" to load the project, because memory consumption is
> much
> >  higher. In this case it also reports back to eglot "loading packages"
> and "finished
> >  loading packages".
> >
> >  Sidenote: However I cannot interact any further with the LS as eglot
> doens't consider
> >  any buffer as managed:
> >
> >  cl-no-applicable-method: No applicable method: eglot--managed-buffers,
> nil
> >  eldoc error: (jsonrpc-error No current JSON-RPC connection
> (jsonrpc-error-code .
> >  32603) (jsonrpc-error-message . No current JSON-RPC connection))
> >  mouse-minibuffer-check: Minibuffer window is not active
> >
> >  but I guess this is because the buffer has no mode eglot considers to
> be supported.
> >
> >  Sidenote2: If I enable go-mode for this buffer (thus triggering
> eglot-ensure in .emacs) ,
> >  a second gopls process is spawned yet without communication between
> eglot and
> >  gopls.
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.