João Távora writes: > On Mon, Sep 16, 2024 at 4:50 PM João Távora wrote: >> >> On Mon, Sep 16, 2024 at 4:40 PM João Távora wrote: >> > >> > On Mon, Sep 16, 2024 at 4:17 PM Brennan Vincent 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.