bug#59883: Eglot gopls failed to connect

bug#59883: Eglot gopls failed to connect

[Johann Höchtl]

[-- Attachment #1: Type: text/plain, Size: 3259 bytes --]

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@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.

[-- Attachment #2: Type: text/html, Size: 4318 bytes --]

bug#59883:

[Johann Höchtl]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1439 bytes --]

bug#59883:

[Johann Höchtl]

[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]

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@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@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.
>

[-- Attachment #2: Type: text/html, Size: 3902 bytes --]

bug#59883:

[Stefan Kangas]

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

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

OK, closed.

bug#59883:

[Johann Höchtl]

[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]

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@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@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@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.
>>
>

[-- Attachment #2: Type: text/html, Size: 4593 bytes --]

bug#59883:

[Stefan Kangas]

reopen 59883
thanks

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

Now done.

bug#59883: Eglot gopls failed to connect

[Stefan Kangas]

Johann Höchtl <johann.hoechtl@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@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@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@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.

bug#59883: Eglot gopls failed to connect

[Johann Höchtl]

[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]

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

> Johann Höchtl <johann.hoechtl@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@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@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@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.
>

[-- Attachment #2: Type: text/html, Size: 4919 bytes --]

bug#59883: Eglot gopls failed to connect

[Stefan Kangas]

Johann Höchtl <johann.hoechtl@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.