bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for :complet


From: Brennan Vincent
Subject: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for :completionItem/resolve
Date: Mon, 16 Sep 2024 13:06:55 -0400

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.

Attachment: BEFORE
Description: Before a8c1559

Attachment: AFTER
Description: After a8c1559

> It should highlight what has changed in the client-server
> communication, if anything.
>
> João

reply via email to

[Prev in Thread] Current Thread [Next in Thread]