GNU bug report logs - #59826
flymake-show-project-diagnotics not updating (eglot for Java with jdtls)

Previous Next

To reply to this bug, email your comments to 59826 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Ventimiglia <davidaventimiglia <at> neptunestation.com>
To: bug-gnu-emacs <at> gnu.org
Cc: joaotavora <at> gmail.com
Subject: flymake-show-project-diagnotics not updating (eglot for Java with
 jdtls)
Date: Sun, 4 Dec 2022 12:38:55 -0800

[Message part 1 (text/plain, inline)]

Hello,

When I run flymake-show-project-diagnostics some warnings are listed for my
Java project. As I jump to those locations and fix the warnings, the
diagnostics buffer doesn't update. One problem I have is that I don't even
know where to begin to look in order to troubleshoot this. It could be a
problem with eglot, jdtls, flymake, or some combination thereof. I started
a GitHub discussion for the eglot project here:

https://github.com/joaotavora/eglot/discussions/1131#discussion-4626934

In summary, for Java if I add say an unused import to a file, jdtls
publishes a diagnostic event for this and the flymake buffer shows a
warning for the unused import.  If I correct the issue by deleting the
unused import, jdtls again publishes a correct diagnostic report for the
file, but the flymake diagnostics buffer doesn't update.

After some correspondence with its maintainer, I believe we ruled out the
jdtls server, since the events buffer seems to show an accurate diagnostics
report being delivered from the server to Emacs/eglot/flymake.  We're
wondering if perhaps the problem lies therefore in eglot and/or flymake.  I
should also say that I'm using the "stock" eglot and flymake built into
Emacs, as I'm using emacs-snapshot.  Here's my Emacs version info:

GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33,
cairo version 1.16.0) of 2022-12-03

I grant that this may not be a bug and could be a mis-configuration, but I
am trying to track that down.  Thanks!

Best,
David Ventimiglia

[Message part 2 (text/html, inline)]

Message #8 received at 59826 <at> debbugs.gnu.org (full text, mbox):

From: David Ventimiglia <davidaventimiglia <at> neptunestation.com>
To: 59826 <at> debbugs.gnu.org
Subject: additional info
Date: Mon, 5 Dec 2022 14:27:31 -0800

[Message part 1 (text/plain, inline)]

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.

[Message part 2 (text/html, inline)]

[eglot.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.