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