bug#59826: additional info

[David Ventimiglia <davidaventimiglia@neptunestation.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2043 bytes --]

Taking an example Java servlet file ProtonServlet.java, when I add an
unused import there's an event like this:

[server-notification] Sun Dec  4 12:01:33 2022:
(:jsonrpc "2.0" :method "textDocument/publishDiagnostics" :params
 (:uri
"file:///home/neptunestationorg/Work/GitHub/ProtonChamber/src/main/java/org/protonchamber/ProtonServlet.java"
:diagnostics
[(:range
 (:start
  (:line 3 :character 7)
  :end
  (:line 3 :character 15))
 :severity 2 :code "268435844" :source "Java" :message "The import java.sql
is never used" :tags
 [1])]))


That makes sense. When I delete the unused import, there's an event like
this:

That also makes sense, as it seems to be that the server is publishing an
empty list of diagnostics for this file. Nevertheless, the
flymake-show-project-diagnostics buffer still has this entry:

ProtonServlet.java            4   8 warning  n        Java [268435844]: The
import java.sql is never used


Also, I see that sometimes warnings are supplied by one back-end, but then
when I fix the issue the same warning is then provided by a different
back-end. Here's what I mean. I have another file with an unused import for
java.sql. When I do, the diagnostics buffer shows an entry from the e-f-b
back-end, which I take to be the "eglot-flymake-backend":

SQLServlet.java               4   7 warning  e-f-b    Java [268435844]: The
import java.sql is never used


If I delete the offending line, the diagnostics buffer replaces that with
this:

SQLServlet.java               4   8 warning  n        Java [268435844]: The
import java.sql is never used


I don't know what the n back-end is, but evidently it's publishing its own
diagnostic for this code 268435844 which somehow is shadowed by the same
diagnostic for the same code from the e-f-b back-end. When the e-f-b
back-end correctly publishes an empty diagnostic report for this file, the
diagnostic report from the n back-end becomes revealed. Or something like
that.

Finally, I was sent a patch, which is attached.  When applied, that seemed
to fix the issue.

[-- Attachment #1.2: Type: text/html, Size: 3225 bytes --]

[-- Attachment #2: eglot.patch --]
[-- Type: text/x-patch, Size: 1189 bytes --]

--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -2048,9 +2048,11 @@ eglot-handle-notification
                     (t          'eglot-note)))
             (mess (source code message)
               (concat source (and code (format " [%s]" code)) ": " message)))
-    (if-let ((buffer (find-buffer-visiting (eglot--uri-to-path uri))))
+    (if-let* ((path (expand-file-name (eglot--uri-to-path uri)))
+              (buffer (find-buffer-visiting path)))
         (with-current-buffer buffer
           (cl-loop
+           initially (assoc-delete-all path flymake-list-only-diagnostics #'string=)
            for diag-spec across diagnostics
            collect (eglot--dbind ((Diagnostic) range code message severity source tags)
                        diag-spec
@@ -2093,7 +2095,6 @@ eglot-handle-notification
                          (t
                           (setq eglot--diagnostics diags)))))
       (cl-loop
-       with path = (expand-file-name (eglot--uri-to-path uri))
        for diag-spec across diagnostics
        collect (eglot--dbind ((Diagnostic) code range message severity source) diag-spec
                  (setq message (mess source code message))