bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for :completionItem/resolve

["Brennan Vincent" <brennan@umanwizard.com>]

Hi João,

Did you get a chance to take a look at my last message? Let me know if I
need to provide any further information.

Thanks
Brennan

"Brennan Vincent" <brennan@umanwizard.com> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> On Mon, Sep 16, 2024 at 4:50 PM João Távora <joaotavora@gmail.com> wrote:
>>>
>>> On Mon, Sep 16, 2024 at 4:40 PM João Távora <joaotavora@gmail.com> wrote:
>>> >
>>> > On Mon, Sep 16, 2024 at 4:17 PM Brennan Vincent <brennan@umanwizard.com> wrote:
>>> >
>>> > > As for the regression: yes, it's a regression from 29.4, and in fact I
>>> > > have bisected to the commit that regressed it:
>>> > > a8c1559a663d9bc21776e33303251e244f86f0d7
>>> >
>>> > Oh alright, that clears it up.  It was an oversight indeed, so I think
>>> > your patch is TRT.  I'll install it in emacs-30.
>>>
>>> Actually, not so fast.  The code before that allegedly broken commit
>>> _also_ sent outstanding changes to the server before resolving
>>> (via the advice that was then removed).
>
> Not according to my testing.
>
> And, taking a look at the old code:
>
> (advice-add #'jsonrpc-request :before
>             (cl-function (lambda (_proc _method _params &key
>                                         deferred &allow-other-keys)
>                            (when (and eglot--managed-mode deferred)
>                              (eglot--signal-textDocument/didChange))))
>             '((name . eglot--signal-textDocument/didChange)))
>
> It seems that we are only sending the changes if the function is called
> with the :deferred flag. The function was NOT called with the :deferred
> flag at the site in question, which as of 093a36 (parent of a8c1559)
> looked like this:
>
> (jsonrpc-request server :completionItem/resolve
>                  lsp-comp :cancel-on-input t)
>
>>>
>>> So I must be missing something, and must investigate more
>>> closely.
>>
>> Brennan, can you provide an excerpt of the Eglot event log
>> (M-x eglot-events-buffer) for your MRE recipe before and
>> after a8c1559a663d9bc21776e33303251e244f86f0d7?
>>
>
> Sure. See attachments. They are a bit long because of the huge doc
> strings rust-analyzer includes, but you should get the idea by searching
> for textDocument/completion.
>
> Note that in BEFORE, we send textDocument/completion, immediately followed by
> completionItem/resolve. In AFTER, we send textDocument/completion, then
> textDocument/didChange, then completionItem/resolve.
>
> (snip)
>
>> It should highlight what has changed in the client-server
>> communication, if anything.
>>
>> João