From unknown Fri Jun 20 20:11:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59826: flymake-show-project-diagnotics not updating (eglot for Java with jdtls) Resent-From: David Ventimiglia Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Dec 2022 23:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 59826 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 59826@debbugs.gnu.org Cc: joaotavora@gmail.com X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.167019586116234 (code B ref -1); Sun, 04 Dec 2022 23:18:02 +0000 Received: (at submit) by debbugs.gnu.org; 4 Dec 2022 23:17:41 +0000 Received: from localhost ([127.0.0.1]:60376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1yEu-0004Dl-FH for submit@debbugs.gnu.org; Sun, 04 Dec 2022 18:17:40 -0500 Received: from lists.gnu.org ([209.51.188.17]:47590) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1vlX-00006x-3P for submit@debbugs.gnu.org; Sun, 04 Dec 2022 15:39:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p1vlW-0004ZG-Ue for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2022 15:39:10 -0500 Received: from mail-oa1-x34.google.com ([2001:4860:4864:20::34]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p1vlU-0000qD-QO for bug-gnu-emacs@gnu.org; Sun, 04 Dec 2022 15:39:10 -0500 Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-143ffc8c2b2so11356027fac.2 for ; Sun, 04 Dec 2022 12:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neptunestation-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=W29jGa/iUJ8ffW7KYeSECh3e5HxFeToufcf6TvvXWrg=; b=MUuAvjlrFhJ2B2+HEFreOh3RvnKR1q7DJNuBTnkWunkgMDyFtoFojRpxj7cd+QVmBX ZOXnFiNHfhHfpxu7e8sBQbWG0JV5bHIFf6pSkPu53IJt8y1N1RZA0obQpwU5y7w+0Kj8 k8tdRQZo5U4Wlvg9ZxZxY2BmyFEQPGcuqiNV7OSbb2NeIX35PN0q5pnlDah49DRpJm06 NjFF/CbTRBYjnwyBoF0hPef9hpBRcYdYde7PKtMbxUCjZr1Mahp+Yq5//630qk2AEZwi NnqglEWnX/UESJ7n++CQFikw/ufHvDUu3OQKbeAflEeE1bsCD2EF24ZTGyAUA7aR2Orx ekMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=W29jGa/iUJ8ffW7KYeSECh3e5HxFeToufcf6TvvXWrg=; b=wmvy+ZceDj99Wcf5ynKRCS6w9EoJSxxH9KruveJqcA3VFBmGR8vKbM7ic5Sci4CU6x +BGSp74/wtObaO7VuvZJTDKvX0rFD2q+4XmPGPwis5fiA4q+sABmipmFvcMlK+d5qfy6 QJT/rz/DLCgKqGWhoIqqjejDLIn5ewINNbcYzbJrld1JKeq7/+lE5YHBnj7glYLx/UTv UFvHoShd4MRtDS9tLHEKjZCdORCMckjNeEaIW7luLvMwIp665GQFWKzZepy6iIH0rqam xfMRSyoFCTNBffj6HVWZVuwCy7h/zc1wbiCik9nCZH6cfjGXqqYRML07sLePDGED9LDN CPbg== X-Gm-Message-State: ANoB5plDrsbQJuLZeEfs+mFYQOnXjD8h0Dup72O5hc+qSO/d/Nw6X3vl sWPTVh2IUREEU+2qBGxUh8u72kF52hE4qKTDcNRQR8S9Fi6HPwQV X-Google-Smtp-Source: AA0mqf5jDLEpPxKoXktfZj8GqKfizX/ylNzN8BrXmg3sfHTwRxPp4SJ1NVe6jOo7LUZlKMKWb/EUkxCIhsnSh+T682A= X-Received: by 2002:a05:6870:c352:b0:132:d3f8:bad4 with SMTP id e18-20020a056870c35200b00132d3f8bad4mr36777679oak.58.1670186346756; Sun, 04 Dec 2022 12:39:06 -0800 (PST) MIME-Version: 1.0 From: David Ventimiglia Date: Sun, 4 Dec 2022 12:38:55 -0800 Message-ID: Content-Type: multipart/alternative; boundary="000000000000e8504205ef068f8c" Received-SPF: pass client-ip=2001:4860:4864:20::34; envelope-from=davidaventimiglia@neptunestation.com; helo=mail-oa1-x34.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Mailman-Approved-At: Sun, 04 Dec 2022 18:17:39 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --000000000000e8504205ef068f8c Content-Type: text/plain; charset="UTF-8" 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 --000000000000e8504205ef068f8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 proble= m I have is that I don't even know where to begin to look in order to t= roubleshoot this. It could be a problem with eglot, jdtls, flymake, or some= combination thereof. I started a GitHub discussion for the eglot project h= ere:


In summary, = for Java if I add say an unused import to a file, jdtls publishes a diagnos= tic event for this and the flymake buffer shows a warning for the unused im= port.=C2=A0 If I correct the issue by deleting the unused import, jdtls aga= in publishes a correct diagnostic report for the file, but the flymake diag= nostics buffer doesn't update.

After some corr= espondence with its maintainer, I believe we ruled out the jdtls server, si= nce the events buffer seems to show an accurate diagnostics report being de= livered from the server to Emacs/eglot/flymake.=C2=A0 We're wondering i= f perhaps the problem lies therefore in eglot and/or flymake.=C2=A0 I shoul= d also say that I'm using the "stock" eglot and flymake built= into Emacs, as I'm using emacs-snapshot.=C2=A0 Here's my Emacs ver= sion info:

GNU Emacs 30.0.50 (build 1, x86_64-pc-l= inux-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.=C2=A0 Thanks!

Best,
David Ventimiglia

--000000000000e8504205ef068f8c-- From unknown Fri Jun 20 20:11:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59826: additional info References: In-Reply-To: Resent-From: David Ventimiglia Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Dec 2022 22:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59826 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 59826@debbugs.gnu.org Received: via spool by 59826-submit@debbugs.gnu.org id=B59826.16702792719021 (code B ref 59826); Mon, 05 Dec 2022 22:28:02 +0000 Received: (at 59826) by debbugs.gnu.org; 5 Dec 2022 22:27:51 +0000 Received: from localhost ([127.0.0.1]:38764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2JwE-0002LR-Dx for submit@debbugs.gnu.org; Mon, 05 Dec 2022 17:27:50 -0500 Received: from mail-oi1-f170.google.com ([209.85.167.170]:40741) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2JwC-0002LL-8y for 59826@debbugs.gnu.org; Mon, 05 Dec 2022 17:27:49 -0500 Received: by mail-oi1-f170.google.com with SMTP id q83so1248262oif.7 for <59826@debbugs.gnu.org>; Mon, 05 Dec 2022 14:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neptunestation-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=kik8ICz/SbtSg6XPCUUy0gKiCmeNyN/PJuTtHzxxJWQ=; b=4OrmLmaeiOWD9YnTCaUVEaALT9hk2t/d1o6Rk51rExPT1So5RZqaEPppkjDXP0+rvU Y4Ku8zT/0SWVKBpC5VVN9sz3eo+Op++/Lac1L7OQGSXn77AHPzUY+vUXM0kBZWHJX9fp ulZxRtIgD3HnHtadFbyEJchkUxO3WnxivAMAWv4hrqPieUgOUsXkhi6Emef6F+u887xr 0g7XGDiXBwGHdBW3TA4IV3KW9uwajxYmDLchSp7ctWhHwyy1F0e413nGoxgdu0rivVe9 kmdoQZYOzwv8COIkI0B2HtzzaMbMmfB7D0KvefEKmD+fNkM7yh7JROtLfuws67TkHLHj lDdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=kik8ICz/SbtSg6XPCUUy0gKiCmeNyN/PJuTtHzxxJWQ=; b=3P8X6PyK1YDC9txDAIajg2nqMfBotOQntR8QcqK71wcLwKe7wUbzTSZf/lzsty3+23 khK1prFMF9qN/HGOdhDcEtX5MX6yiYbmUPT0s4X37dQ1Fw6Iob40/OjH3Ip2L9H2tpAC s6lzKCRC1FFsmunk/NM0L6P0uKxj9Mc9M+KkXP/s7QFzazrRZAdCP93xq25BJoG5sfiS nzEsX/JS3OvNF3uFo7ck+SmDUwpxsSiAhCuS2fD8dCPbYtKKYqPTmVM9SEyqIciMTqro ngDOpSPGIXl2FJd9yvH2MmalhnhbSNa+u83FWB8xpA6kZbqnMXdCipcac2dutYn11UHB hAbw== X-Gm-Message-State: ANoB5pl04cL0bJ6oiP0DVvCj40pWKoAcNjLlzk24zDe0fn3BNXf2Xv1K wxwehsue7eeBuY6S4I0TLKO4ZAVKrSm9oYJ/mHefEm+LHJHQX8GR X-Google-Smtp-Source: AA0mqf4s5uCXHbwYCGRzIcFURdaz12Yycpk9ILVpyTGFr2OrnIOmNZQP5br63I3VXqMGItCxGhN4ByE2MA8bG2rBVLI= X-Received: by 2002:a05:6808:1818:b0:35a:6cfb:f03b with SMTP id bh24-20020a056808181800b0035a6cfbf03bmr31725416oib.58.1670279262274; Mon, 05 Dec 2022 14:27:42 -0800 (PST) MIME-Version: 1.0 From: David Ventimiglia Date: Mon, 5 Dec 2022 14:27:31 -0800 Message-ID: Content-Type: multipart/mixed; boundary="0000000000001ae39105ef1c3293" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000001ae39105ef1c3293 Content-Type: multipart/alternative; boundary="0000000000001ae38f05ef1c3291" --0000000000001ae38f05ef1c3291 Content-Type: text/plain; charset="UTF-8" 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. --0000000000001ae38f05ef1c3291 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Taking an example Java servlet file ProtonServlet.java, wh= en I add an unused import there's an event like this:

[server-notification] Sun Dec =C2=A04 12:01:33 2022:
<= div>(:jsonrpc "2.0" :method "textDo= cument/publishDiagnostics" :params
=C2=A0(:uri "file:///home/neptunestationorg/Work/GitHub/Proto= nChamber/src/main/java/org/protonchamber/ProtonServlet.java" :diagnost= ics
[(:range
<= font face=3D"monospace"> =C2=A0(:start
=C2=A0 (:line 3 :character 7)
=C2=A0 :end
=C2=A0 = (:line 3 :character 15))
=C2= =A0:severity 2 :code "268435844" :source "Java" :messag= e "The import java.sql is never used" :tags
=C2=A0[1])]))

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

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

ProtonServlet.java =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04 =C2=A0 8 warning =C2=A0n =C2=A0 =C2=A0 = =C2=A0 =C2=A0Java [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 anot= her file with an unused import for java.sql. When I do, the diagnostics buf= fer shows an entry from the e-f-b back-end, which I take to be the "eg= lot-flymake-backend":

SQLServlet.java =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4 =C2=A0 7 warning =C2=A0e-f-= b =C2=A0 =C2=A0Java [268435844]: The import java.sql is never used

If I delete the offending line, the di= agnostics buffer replaces that with this:

SQLServlet.java =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = 4 =C2=A0 8 warning =C2=A0n =C2=A0 =C2=A0 =C2=A0 =C2=A0Java [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 th= e 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 at= tached.=C2=A0 When applied, that seemed to fix the issue.
--0000000000001ae38f05ef1c3291-- --0000000000001ae39105ef1c3293 Content-Type: text/x-patch; charset="US-ASCII"; name="eglot.patch" Content-Disposition: attachment; filename="eglot.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lbbd3sie0 LS0tIGEvbGlzcC9wcm9nbW9kZXMvZWdsb3QuZWwKKysrIGIvbGlzcC9wcm9nbW9kZXMvZWdsb3Qu ZWwKQEAgLTIwNDgsOSArMjA0OCwxMSBAQCBlZ2xvdC1oYW5kbGUtbm90aWZpY2F0aW9uCiAgICAg ICAgICAgICAgICAgICAgICh0ICAgICAgICAgICdlZ2xvdC1ub3RlKSkpCiAgICAgICAgICAgICAo bWVzcyAoc291cmNlIGNvZGUgbWVzc2FnZSkKICAgICAgICAgICAgICAgKGNvbmNhdCBzb3VyY2Ug KGFuZCBjb2RlIChmb3JtYXQgIiBbJXNdIiBjb2RlKSkgIjogIiBtZXNzYWdlKSkpCi0gICAgKGlm LWxldCAoKGJ1ZmZlciAoZmluZC1idWZmZXItdmlzaXRpbmcgKGVnbG90LS11cmktdG8tcGF0aCB1 cmkpKSkpCisgICAgKGlmLWxldCogKChwYXRoIChleHBhbmQtZmlsZS1uYW1lIChlZ2xvdC0tdXJp LXRvLXBhdGggdXJpKSkpCisgICAgICAgICAgICAgIChidWZmZXIgKGZpbmQtYnVmZmVyLXZpc2l0 aW5nIHBhdGgpKSkKICAgICAgICAgKHdpdGgtY3VycmVudC1idWZmZXIgYnVmZmVyCiAgICAgICAg ICAgKGNsLWxvb3AKKyAgICAgICAgICAgaW5pdGlhbGx5IChhc3NvYy1kZWxldGUtYWxsIHBhdGgg Zmx5bWFrZS1saXN0LW9ubHktZGlhZ25vc3RpY3MgIydzdHJpbmc9KQogICAgICAgICAgICBmb3Ig ZGlhZy1zcGVjIGFjcm9zcyBkaWFnbm9zdGljcwogICAgICAgICAgICBjb2xsZWN0IChlZ2xvdC0t ZGJpbmQgKChEaWFnbm9zdGljKSByYW5nZSBjb2RlIG1lc3NhZ2Ugc2V2ZXJpdHkgc291cmNlIHRh Z3MpCiAgICAgICAgICAgICAgICAgICAgICAgIGRpYWctc3BlYwpAQCAtMjA5Myw3ICsyMDk1LDYg QEAgZWdsb3QtaGFuZGxlLW5vdGlmaWNhdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICh0 CiAgICAgICAgICAgICAgICAgICAgICAgICAgIChzZXRxIGVnbG90LS1kaWFnbm9zdGljcyBkaWFn cykpKSkpCiAgICAgICAoY2wtbG9vcAotICAgICAgIHdpdGggcGF0aCA9IChleHBhbmQtZmlsZS1u YW1lIChlZ2xvdC0tdXJpLXRvLXBhdGggdXJpKSkKICAgICAgICBmb3IgZGlhZy1zcGVjIGFjcm9z cyBkaWFnbm9zdGljcwogICAgICAgIGNvbGxlY3QgKGVnbG90LS1kYmluZCAoKERpYWdub3N0aWMp IGNvZGUgcmFuZ2UgbWVzc2FnZSBzZXZlcml0eSBzb3VyY2UpIGRpYWctc3BlYwogICAgICAgICAg ICAgICAgICAoc2V0cSBtZXNzYWdlIChtZXNzIHNvdXJjZSBjb2RlIG1lc3NhZ2UpKQ== --0000000000001ae39105ef1c3293--