Subject: bug#59826: additional info

From: David Ventimiglia <[email-masked]>
Date: Mon, 5 Dec 2022 14:27:31 -0800

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.
--- 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))