Subject: Re:

From: Johann Höchtl <[email-masked]>
Date: Mon, 12 Dec 2022 08:13:42 +0100

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 <
[email-masked]>:

> 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 <
> [email-masked]>:
>
>> 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.
>>
>