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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 59883 in the body.
You can then email your comments to 59883 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Eglot gopls failed to connect
Date: Wed, 7 Dec 2022 14:50:35 +0100

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

Using Emacs build
https://github.com/kiennq/emacs-build/releases/tag/v29.169.20221201.4a23421


has builtin eglot: yes

Running under git bash,Windows 10, German

I am developing golang, the go LSP server is gopls. Installed @latest from

golang.org/x/tools/gopls v0.10.1
    golang.org/x/tools/gopls <at> v0.10.1
h1:JoHe17pdZ8Vsa24/GUO8iTVTKPh0EOBiWpPop7XJybI=

Messages are:

[eglot] Connected! Server `gopls' now managing `(go-mode go-dot-mod-mode
go-dot-work-mode)' buffers in project `kennzahlenmonitor'.
Error in menu-bar-update-hook (imenu-update-menubar): (jsonrpc-error
"request id=2 failed:" (jsonrpc-error-message . "Timed out"))


The EGLOT Buffer has these entries:
[client-notification] Wed Dec  7 14:43:57 2022:
(:jsonrpc "2.0" :method "textDocument/didOpen" :params
 (:textDocument
  (:uri
"file:///c%3A/Users/HoechtlJ/code/kennzahlenmonitor/kennzahlenmonitor/units/serviceware/serviceware.go"
:version 0 :languageId "go" :text
 [... snip ...]

[client-request] (id:6) Wed Dec  7 14:43:58 2022:
(:jsonrpc "2.0" :id 6 :method "textDocument/documentSymbol" :params
 (:textDocument
  (:uri
"file:///c%3A/Users/HoechtlJ/code/kennzahlenmonitor/kennzahlenmonitor/units/serviceware/serviceware.go")))
[client-request] (id:7) Wed Dec  7 14:44:13 2022:
(:jsonrpc "2.0" :id 7 :method "textDocument/signatureHelp" :params
 (:textDocument
  (:uri
"file:///c%3A/Users/HoechtlJ/code/kennzahlenmonitor/kennzahlenmonitor/units/serviceware/serviceware.go")
  :position
  (:line 0 :character 0)))
[client-request] (id:8) Wed Dec  7 14:44:13 2022:
(:jsonrpc "2.0" :id 8 :method "textDocument/hover" :params
 (:textDocument
  (:uri
"file:///c%3A/Users/HoechtlJ/code/kennzahlenmonitor/kennzahlenmonitor/units/serviceware/serviceware.go")
  :position
  (:line 0 :character 0)))
[client-request] (id:9) Wed Dec  7 14:44:13 2022:
(:jsonrpc "2.0" :id 9 :method "textDocument/documentHighlight" :params
 (:textDocument
  (:uri
"file:///c%3A/Users/HoechtlJ/code/kennzahlenmonitor/kennzahlenmonitor/units/serviceware/serviceware.go")
  :position
  (:line 0 :character 0)))
[internal] (id:7) Wed Dec  7 14:44:23 2022:
(:timed-out :textDocument/signatureHelp :id 7 :params
(:textDocument
(:uri
"file:///c%3A/Users/HoechtlJ/code/kennzahlenmonitor/kennzahlenmonitor/units/serviceware/serviceware.go")
:position
(:line 0 :character 0)))
[internal] (id:8) Wed Dec  7 14:44:23 2022:
(:timed-out :textDocument/hover :id 8 :params
(:textDocument
(:uri
"file:///c%3A/Users/HoechtlJ/code/kennzahlenmonitor/kennzahlenmonitor/units/serviceware/serviceware.go")
:position
(:line 0 :character 0)))
[internal] (id:9) Wed Dec  7 14:44:23 2022:
(:timed-out :textDocument/documentHighlight :id 9 :params
(:textDocument
(:uri
"file:///c%3A/Users/HoechtlJ/code/kennzahlenmonitor/kennzahlenmonitor/units/serviceware/serviceware.go")
:position
(:line 0 :character 0)))

Symptom is, that the LSP server is running but actually not in a working
state. Memory consumption is stable (low) but the server doens't seem to
respond to request.

If the project is very small, the server works.

It seems the server is not yet ready scanning packages yet has to answer
requests.

Under some very rare circumstances even on a large codebase gopls works.
Icouldn't yet identify a pattern when this is the case.

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

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

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: 59883 <at> debbugs.gnu.org
Date: Sun, 11 Dec 2022 13:45:59 +0100

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

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)]

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

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: 59883 <at> debbugs.gnu.org
Subject: Re:
Date: Sun, 11 Dec 2022 14:24:00 +0100

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

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)]

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>, 
 59883-done <at> debbugs.gnu.org
Subject: Re: bug#59883:
Date: Sun, 11 Dec 2022 10:35:33 -0800

Johann Höchtl <johann.hoechtl <at> gmail.com> writes:

> This bug report may be closed, reported for reference.

OK, closed.

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

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: 59883 <at> debbugs.gnu.org
Subject: Re:
Date: Mon, 12 Dec 2022 08:13:42 +0100

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

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.

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)]

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>, 
 59883 <at> debbugs.gnu.org
Subject: Re: bug#59883:
Date: Sun, 11 Dec 2022 23:46:45 -0800

reopen 59883
thanks

> Sorry, this bug has to be re-opened.

Now done.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Johann Höchtl <johann.hoechtl <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 12:21:10 -0700

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?

> 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 #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)]

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

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

Johann Höchtl <johann.hoechtl <at> gmail.com> writes:

>> Are you still seeing this?
>
> No, for me it was fixed with an update to jsonrpc which was then included
> into emacs 29.1.

Thanks for reporting back.  I'm therefore closing this bug report.

Previous Next

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