On Tue, Apr 8, 2025, 14:46 JD Smith <jdtsmith@gmail.com> wrote:.

I meant LSP version identifiers.  After my success solving the current
> problem using them, I believe ensuring the document version the LSP server
> worked against when working up a response to the diagnostic pull request
> matches the current version is vitally important.  Luckily this looks to be
> straightforward.
>

Yes.

I'll take it under consideration, though I suspect it would be 10x easier
> for someone more familiar with eglot's semantics and code conventions,
> which are more complex than typical packages.
>

The main difficulty seems to be finding a server which supports this mode.
Clangd and basedpyright don't seem to.

>
> Thanks.  This tests fine on master.  Performance in my large python buffer
> is now refreshingly acceptable.  Two questions:
>
> - Can we be certain that `eglot--versioned-identifier' is always an
> integer?
>

No. It can be nil. But what it's not nil, it's an integer as specified in
the standard.

- Any reason not to implement this on the emacs-30 branch?


Eglot is a GNU Elpa :core package and so it has its own release rhythm.

I don't think the LSP server is to blame here.  Yes, it's sending large
> messages (too often) and getting behind, but it is dutifully providing the
> document version number.


I beg to differ. A server that is sending useless junk down the wire,
however legal that junk is, is a server that should be fixed. As you well
know, performance problems arise often from just parsing JSON into
expensive Lisp structures.

João