aboutsummaryrefslogtreecommitdiffstats
path: root/java
diff options
context:
space:
mode:
authorJoão Távora2025-04-17 00:31:07 +0100
committerJoão Távora2025-04-17 00:31:38 +0100
commitc5b97b7b321c873dbe8a36d27781435ba10a2278 (patch)
treee724c6f583a293ce7e81d7f525b951a3759d49f5 /java
parent2330e7b6d676761b60c3247f53224815512a9a58 (diff)
downloademacs-c5b97b7b321c873dbe8a36d27781435ba10a2278.tar.gz
emacs-c5b97b7b321c873dbe8a36d27781435ba10a2278.zip
Eglot: be aware of LSP version of contextual diagnostics
In certain situations, Eglot has to report to the server parts of the diagnostics that it itself sent us. The server may use this as context to compute code actions, for example. Eglot selects diagnostics by asking Flymake, looking for the ones that contain Eglot-specific cookies. But when doing so, it is important to also be aware of the LSP document version these each of these diagnostics pertain to, since if a diagonstic in the buffer pertains to an older version of the LSP document (because Flymake fired or the server hasn't pushed a new set), that diagnostics 'eglot-lsp-data' cookie is invalid and possibly harmful. An example is when a diagnostic extends all the way to the end of the buffer. If we attempt to fix by shortening the buffer, an Eldoc-started code actions request may be sent to the server considering the soon-to-be-deleted Flymake diagnostic as context. But that diagnostic's 'eglot-lsp-data' cookie is no longer valid and when processing that context we try to go past point-max and burp an annoying error. Best to check the version of the diagnostic (if we have it) and ignore the ones that don't match the document version. * lisp/progmodes/eglot.el (eglot--versioned-identifier): Move up. (eglot--flymake-diagnostics, eglot--diag-to-lsp-diag): New helpers. (eglot-handle-notification): Record LSP doc version in diagnostics. (eglot--code-action-bounds) (eglot--code-action-params): Use eglot--flymake-diagnostics.
Diffstat (limited to 'java')
0 files changed, 0 insertions, 0 deletions