unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#59883: Eglot gopls failed to connect
@ 2022-12-07 13:50 Johann Höchtl
  2022-12-11 12:45 ` bug#59883: Johann Höchtl
  0 siblings, 1 reply; 9+ messages in thread
From: Johann Höchtl @ 2022-12-07 13:50 UTC (permalink / raw)
  To: 59883

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59883:
  2022-12-07 13:50 bug#59883: Eglot gopls failed to connect Johann Höchtl
@ 2022-12-11 12:45 ` Johann Höchtl
  2022-12-11 13:24   ` bug#59883: Johann Höchtl
  0 siblings, 1 reply; 9+ messages in thread
From: Johann Höchtl @ 2022-12-11 12:45 UTC (permalink / raw)
  To: 59883

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59883:
  2022-12-11 12:45 ` bug#59883: Johann Höchtl
@ 2022-12-11 13:24   ` Johann Höchtl
  2022-12-11 18:35     ` bug#59883: Stefan Kangas
  2022-12-12  7:13     ` bug#59883: Johann Höchtl
  0 siblings, 2 replies; 9+ messages in thread
From: Johann Höchtl @ 2022-12-11 13:24 UTC (permalink / raw)
  To: 59883

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59883:
  2022-12-11 13:24   ` bug#59883: Johann Höchtl
@ 2022-12-11 18:35     ` Stefan Kangas
  2022-12-12  7:13     ` bug#59883: Johann Höchtl
  1 sibling, 0 replies; 9+ messages in thread
From: Stefan Kangas @ 2022-12-11 18:35 UTC (permalink / raw)
  To: Johann Höchtl, 59883-done

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

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

OK, closed.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59883:
  2022-12-11 13:24   ` bug#59883: Johann Höchtl
  2022-12-11 18:35     ` bug#59883: Stefan Kangas
@ 2022-12-12  7:13     ` Johann Höchtl
  2022-12-12  7:46       ` bug#59883: Stefan Kangas
  2023-09-10 19:21       ` bug#59883: Eglot gopls failed to connect Stefan Kangas
  1 sibling, 2 replies; 9+ messages in thread
From: Johann Höchtl @ 2022-12-12  7:13 UTC (permalink / raw)
  To: 59883

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59883:
  2022-12-12  7:13     ` bug#59883: Johann Höchtl
@ 2022-12-12  7:46       ` Stefan Kangas
  2023-09-10 19:21       ` bug#59883: Eglot gopls failed to connect Stefan Kangas
  1 sibling, 0 replies; 9+ messages in thread
From: Stefan Kangas @ 2022-12-12  7:46 UTC (permalink / raw)
  To: Johann Höchtl, 59883

reopen 59883
thanks

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

Now done.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59883: Eglot gopls failed to connect
  2022-12-12  7:13     ` bug#59883: Johann Höchtl
  2022-12-12  7:46       ` bug#59883: Stefan Kangas
@ 2023-09-10 19:21       ` Stefan Kangas
  2023-09-10 19:29         ` Johann Höchtl
  1 sibling, 1 reply; 9+ messages in thread
From: Stefan Kangas @ 2023-09-10 19:21 UTC (permalink / raw)
  To: Johann Höchtl; +Cc: João Távora, 59883

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.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59883: Eglot gopls failed to connect
  2023-09-10 19:21       ` bug#59883: Eglot gopls failed to connect Stefan Kangas
@ 2023-09-10 19:29         ` Johann Höchtl
  2023-09-10 19:35           ` Stefan Kangas
  0 siblings, 1 reply; 9+ messages in thread
From: Johann Höchtl @ 2023-09-10 19:29 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: João Távora, 59883

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#59883: Eglot gopls failed to connect
  2023-09-10 19:29         ` Johann Höchtl
@ 2023-09-10 19:35           ` Stefan Kangas
  0 siblings, 0 replies; 9+ messages in thread
From: Stefan Kangas @ 2023-09-10 19:35 UTC (permalink / raw)
  To: Johann Höchtl; +Cc: João Távora, 59883-done

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.





^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2023-09-10 19:35 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-12-07 13:50 bug#59883: Eglot gopls failed to connect Johann Höchtl
2022-12-11 12:45 ` bug#59883: Johann Höchtl
2022-12-11 13:24   ` bug#59883: Johann Höchtl
2022-12-11 18:35     ` bug#59883: Stefan Kangas
2022-12-12  7:13     ` bug#59883: Johann Höchtl
2022-12-12  7:46       ` bug#59883: Stefan Kangas
2023-09-10 19:21       ` bug#59883: Eglot gopls failed to connect Stefan Kangas
2023-09-10 19:29         ` Johann Höchtl
2023-09-10 19:35           ` Stefan Kangas

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).