GNU bug report logs - #66726
29.1; Eglot jdtls formatter ignored

Previous Next

To reply to this bug, email your comments to 66726 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: Cay Horstmann <cay <at> horstmann.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; Eglot jdtls formatter ignored
Date: Tue, 24 Oct 2023 11:17:09 +0200

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

Eglot does not trigger a custom formatter with jdtls, while lsp-java and VS Code with the Red Hat Java plugin can do this. See https://github.com/joaotavora/eglot/discussions/1222 for more background.

I attach files
* eglot-debug.el (the minimal configuration to see the failure)
* NotHelloWorld.java (a sample Java file)
* cay-eclipse-formatter.xml (the formatting rules for jdtls)
* eglot-events.txt (the events log from eglot)
* lsp-java-debug.el (the minimal configuration to see how it works with lsp-java)
* lsp-log.txt (the log from the successful run with lsp)

Download jdtls from https://download.eclipse.org/jdtls/snapshots/?d. I
have the version from Oct. 14, 2023. Put it somewhere on your PATH

Put the NotHelloWorld.java file in some directory (I use /tmp/hello)

Put the cay-eclipse-formatter.xml file somewhere and adjust the path in eglot-debug.el and lsp-java-debug.el.

emacs -q -l eglot-debug.el /tmp/hello/NotHelloWorld.java

M-x eglot RET

Wait for jdtls to start

M-x eglot-format-buffer RET

The formatting should now use the rules in the cay-eclipse-formatter.xml
file, resulting in 8 changes but the same Allman indentation
style. Instead, it uses a K&R indentation style.

To see the proper formatting, install lsp-mode and lsp-java and start with lsp-java-debug.el. Or use VS Code with the Red Hat Java plugin and the settings.json

{
    "java.format.settings.url": "file:///data/cay/bin/cay-eclipse.formatter.xml",
    "java.format.settings.profile": "cay"
}



In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33,
 cairo version 1.16.0) of 2023-08-15 built on cay-ThinkPad-X1-Yoga-Gen-7
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Ubuntu 22.04.3 LTS

Configured using:
 'configure --with-tree-sitter'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM XINPUT2 XPM
GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: de_DE.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_DK.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Java//l

Minor modes in effect:
  eglot-inlay-hints-mode: t
  eglot--managed-mode: t
  flymake-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny rfc822
mml mml-sec epa derived epg rfc6068 epg-config gnus-util mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
files-x find-dired dired dired-loaddefs grep time-date cl-extra cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs eglot external-completion array filenotify jsonrpc ert pp ewoc
debug backtrace help-mode find-func xref flymake-proc flymake thingatpt
warnings icons compile text-property-search comint ansi-osc ansi-color
ring pcase url-util url-parse auth-source cl-seq eieio eieio-core
cl-macs password-cache json subr-x map url-vars project byte-opt gv
bytecomp byte-compile imenu cl-loaddefs cl-lib rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 107858 9131)
 (symbols 48 11792 0)
 (strings 32 34568 1702)
 (string-bytes 1 1192636)
 (vectors 16 23157)
 (vector-slots 8 313544 12514)
 (floats 8 39 90)
 (intervals 56 661 0)
 (buffers 984 18))

[eglot-debug.el (text/x-emacs-lisp, attachment)]

[lsp-java-debug.el (text/x-emacs-lisp, attachment)]

[NotHelloWorld.java (text/x-java, attachment)]

[cay-eclipse.formatter.xml (text/xml, attachment)]

[eglot-events.txt (text/plain, attachment)]

[lsp-log.txt (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cay Horstmann <cay <at> horstmann.com>, João Távora
 <joaotavora <at> gmail.com>
Cc: 66726 <at> debbugs.gnu.org
Subject: Re: bug#66726: 29.1; Eglot jdtls formatter ignored
Date: Sun, 29 Oct 2023 14:08:21 +0200

> Date: Tue, 24 Oct 2023 11:17:09 +0200
> From: Cay Horstmann <cay <at> horstmann.com>
> 
> Eglot does not trigger a custom formatter with jdtls, while lsp-java and VS Code with the Red Hat Java plugin can do this. See https://github.com/joaotavora/eglot/discussions/1222 for more background.
> 
> I attach files
> * eglot-debug.el (the minimal configuration to see the failure)
> * NotHelloWorld.java (a sample Java file)
> * cay-eclipse-formatter.xml (the formatting rules for jdtls)
> * eglot-events.txt (the events log from eglot)
> * lsp-java-debug.el (the minimal configuration to see how it works with lsp-java)
> * lsp-log.txt (the log from the successful run with lsp)
> 
> Download jdtls from https://download.eclipse.org/jdtls/snapshots/?d. I
> have the version from Oct. 14, 2023. Put it somewhere on your PATH
> 
> Put the NotHelloWorld.java file in some directory (I use /tmp/hello)
> 
> Put the cay-eclipse-formatter.xml file somewhere and adjust the path in eglot-debug.el and lsp-java-debug.el.
> 
> emacs -q -l eglot-debug.el /tmp/hello/NotHelloWorld.java
> 
> M-x eglot RET
> 
> Wait for jdtls to start
> 
> M-x eglot-format-buffer RET
> 
> The formatting should now use the rules in the cay-eclipse-formatter.xml
> file, resulting in 8 changes but the same Allman indentation
> style. Instead, it uses a K&R indentation style.
> 
> To see the proper formatting, install lsp-mode and lsp-java and start with lsp-java-debug.el. Or use VS Code with the Red Hat Java plugin and the settings.json
> 
> {
>      "java.format.settings.url": "file:///data/cay/bin/cay-eclipse.formatter.xml",
>      "java.format.settings.profile": "cay"
> }

João, any comments?

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

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66726 <at> debbugs.gnu.org, Cay Horstmann <cay <at> horstmann.com>
Subject: Re: bug#66726: 29.1; Eglot jdtls formatter ignored
Date: Sun, 29 Oct 2023 14:40:02 +0000

On Sun, Oct 29, 2023 at 12:08 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Date: Tue, 24 Oct 2023 11:17:09 +0200
> > From: Cay Horstmann <cay <at> horstmann.com>
> >
> > Eglot does not trigger a custom formatter with jdtls, while lsp-java and VS Code with the Red Hat Java plugin can do this. See https://github.com/joaotavora/eglot/discussions/1222 for more background.
> >
> > I attach files
> > * eglot-debug.el (the minimal configuration to see the failure)
> > * NotHelloWorld.java (a sample Java file)
> > * cay-eclipse-formatter.xml (the formatting rules for jdtls)
> > * eglot-events.txt (the events log from eglot)
> > * lsp-java-debug.el (the minimal configuration to see how it works with lsp-java)
> > * lsp-log.txt (the log from the successful run with lsp)
> >
> > Download jdtls from https://download.eclipse.org/jdtls/snapshots/?d. I
> > have the version from Oct. 14, 2023. Put it somewhere on your PATH
> >
> > Put the NotHelloWorld.java file in some directory (I use /tmp/hello)
> >
> > Put the cay-eclipse-formatter.xml file somewhere and adjust the path in eglot-debug.el and lsp-java-debug.el.
> >
> > emacs -q -l eglot-debug.el /tmp/hello/NotHelloWorld.java
> >
> > M-x eglot RET
> >
> > Wait for jdtls to start
> >
> > M-x eglot-format-buffer RET
> >
> > The formatting should now use the rules in the cay-eclipse-formatter.xml
> > file, resulting in 8 changes but the same Allman indentation
> > style. Instead, it uses a K&R indentation style.
> >
> > To see the proper formatting, install lsp-mode and lsp-java and start with lsp-java-debug.el. Or use VS Code with the Red Hat Java plugin and the settings.json
> >
> > {
> >      "java.format.settings.url": "file:///data/cay/bin/cay-eclipse.formatter.xml",
> >      "java.format.settings.profile": "cay"
> > }
>
> João, any comments?

Not many.  Seems like a good error recipe, assuming someone
finds the time to reproduce it.  If I had to guess, I'd say
almost surely a server-side quirk about it not finding the
xml file from that slightly strange url.  Maybe lsp-mode is
setting some environment variable.  But that would
require me debugging Java which I haven't done in just
about 20 years and not really looking forward to.

Cay, is there some kind of jtdls error log where it reports
things?  Can you also attach the Eglot stderr buffer, in case
it has something useful?  Use `M-x eglot-stderr-buffer`.

The only thing that seems to be missing is the Emacs version,
but I'll assume it's the version used in M-x report-emacs-bug
itself, which is 29.1.

João

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

From: Cay Horstmann <cay <at> horstmann.com>
To: João Távora <joaotavora <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 66726 <at> debbugs.gnu.org
Subject: Re: bug#66726: 29.1; Eglot jdtls formatter ignored
Date: Mon, 6 Nov 2023 18:16:01 +0100

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

On 29/10/2023 15.40, João Távora wrote:
> On Sun, Oct 29, 2023 at 12:08 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>>> Date: Tue, 24 Oct 2023 11:17:09 +0200
>>> From: Cay Horstmann <cay <at> horstmann.com>
>>>
>>> Eglot does not trigger a custom formatter with jdtls, while lsp-java and VS Code with the Red Hat Java plugin can do this. See https://github.com/joaotavora/eglot/discussions/1222 for more background.
>>>
>>> I attach files
>>> * eglot-debug.el (the minimal configuration to see the failure)
>>> * NotHelloWorld.java (a sample Java file)
>>> * cay-eclipse-formatter.xml (the formatting rules for jdtls)
>>> * eglot-events.txt (the events log from eglot)
>>> * lsp-java-debug.el (the minimal configuration to see how it works with lsp-java)
>>> * lsp-log.txt (the log from the successful run with lsp)
>>>
>>> Download jdtls from https://download.eclipse.org/jdtls/snapshots/?d. I
>>> have the version from Oct. 14, 2023. Put it somewhere on your PATH
>>>
>>> Put the NotHelloWorld.java file in some directory (I use /tmp/hello)
>>>
>>> Put the cay-eclipse-formatter.xml file somewhere and adjust the path in eglot-debug.el and lsp-java-debug.el.
>>>
>>> emacs -q -l eglot-debug.el /tmp/hello/NotHelloWorld.java
>>>
>>> M-x eglot RET
>>>
>>> Wait for jdtls to start
>>>
>>> M-x eglot-format-buffer RET
>>>
>>> The formatting should now use the rules in the cay-eclipse-formatter.xml
>>> file, resulting in 8 changes but the same Allman indentation
>>> style. Instead, it uses a K&R indentation style.
>>>
>>> To see the proper formatting, install lsp-mode and lsp-java and start with lsp-java-debug.el. Or use VS Code with the Red Hat Java plugin and the settings.json
>>>
>>> {
>>>       "java.format.settings.url": "file:///data/cay/bin/cay-eclipse.formatter.xml",
>>>       "java.format.settings.profile": "cay"
>>> }
>>
>> João, any comments?
> 
> Not many.  Seems like a good error recipe, assuming someone
> finds the time to reproduce it.  If I had to guess, I'd say
> almost surely a server-side quirk about it not finding the
> xml file from that slightly strange url.  Maybe lsp-mode is
> setting some environment variable.  But that would
> require me debugging Java which I haven't done in just
> about 20 years and not really looking forward to.
> 
> Cay, is there some kind of jtdls error log where it reports
> things?  Can you also attach the Eglot stderr buffer, in case
> it has something useful?  Use `M-x eglot-stderr-buffer`.
> 
> The only thing that seems to be missing is the Emacs version,
> but I'll assume it's the version used in M-x report-emacs-bug
> itself, which is 29.1.
> 
> João

Hello, here is another stab at this.

* There is no problem with that funny looking file:/// URL. jdtls can find it when invoked from VS Code and lsp-mode.

* I attach the initialization that happens from VS Code. It looks just like the one that I am setting up in eglot. Look at the path initializationOptions.settings.java.format.settings.

Formatting works fine in VS Code. The logs show requests such as this one:

[Trace - 3:51:32 PM] Sending request 'textDocument/formatting - (71)'.
Params: {
    "textDocument": {
        "uri": "file:///tmp/test/NotHelloWorld.java"
    },
    "options": {
        "tabSize": 4,
        "insertSpaces": true
    }
}

These look just like the ones that eglot sends. But the response is a formatting directive that follows the formatter, whereas with eglot, the response is a directive that follows some default.

* Here is the requested eglot-stderr-buffer:

WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
Nov 06, 2023 4:20:36 PM org.apache.aries.spifly.BaseActivator log
INFO: Registered provider ch.qos.logback.classic.servlet.LogbackServletContainerInitializer of service jakarta.servlet.ServletContainerInitializer in bundle ch.qos.logback.classic
Nov 06, 2023 4:20:36 PM org.apache.aries.spifly.BaseActivator log
INFO: Registered provider ch.qos.logback.classic.spi.LogbackServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle ch.qos.logback.classic

* Yes, it is Emacs 29.1.

* The jdtls logs are a mystery to me. According to https://github.com/eclipse-jdtls/eclipse.jdt.ls/issues/752#issuecomment-412275314,

"Should be in workspace/.metadata/.log, workspace location is a parameter you pass when starting the server."

Who is "you"? I suppose the client, i.e. eglot or VS Code. I find files such as

./eglot-java-eclipse-jdt-cache/a397d9cc217eb5e87ff722051c2f059b/.metadata/.log

but they don't contain any info on today's interactions. There is no other directory in that cache. I can tell from that log that the directory was passed as a --data command-line argument. But when I intercept jdtls today via a script to log the command-line args, there is no --data command-line argument passed when invoking jdtls.

Thanks,

Cay

--

Cay S. Horstmann | http://horstmann.com | mailto:cay <at> horstmann.com

[vs-code-jdtls.log (text/x-log, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: joaotavora <at> gmail.com, Cay Horstmann <cay <at> horstmann.com>
Cc: 66726 <at> debbugs.gnu.org
Subject: Re: bug#66726: 29.1; Eglot jdtls formatter ignored
Date: Sat, 18 Nov 2023 10:40:03 +0200

> Date: Mon, 6 Nov 2023 18:16:01 +0100
> From: Cay Horstmann <cay <at> horstmann.com>
> Cc: 66726 <at> debbugs.gnu.org
> 
> > Cay, is there some kind of jtdls error log where it reports
> > things?  Can you also attach the Eglot stderr buffer, in case
> > it has something useful?  Use `M-x eglot-stderr-buffer`.
> > 
> > The only thing that seems to be missing is the Emacs version,
> > but I'll assume it's the version used in M-x report-emacs-bug
> > itself, which is 29.1.
> > 
> > João
> 
> Hello, here is another stab at this.
> 
> * There is no problem with that funny looking file:/// URL. jdtls can find it when invoked from VS Code and lsp-mode.
> 
> * I attach the initialization that happens from VS Code. It looks just like the one that I am setting up in eglot. Look at the path initializationOptions.settings.java.format.settings.
> 
> Formatting works fine in VS Code. The logs show requests such as this one:
> 
> [Trace - 3:51:32 PM] Sending request 'textDocument/formatting - (71)'.
> Params: {
>      "textDocument": {
>          "uri": "file:///tmp/test/NotHelloWorld.java"
>      },
>      "options": {
>          "tabSize": 4,
>          "insertSpaces": true
>      }
> }
> 
> These look just like the ones that eglot sends. But the response is a formatting directive that follows the formatter, whereas with eglot, the response is a directive that follows some default.
> 
> * Here is the requested eglot-stderr-buffer:
> 
> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
> Nov 06, 2023 4:20:36 PM org.apache.aries.spifly.BaseActivator log
> INFO: Registered provider ch.qos.logback.classic.servlet.LogbackServletContainerInitializer of service jakarta.servlet.ServletContainerInitializer in bundle ch.qos.logback.classic
> Nov 06, 2023 4:20:36 PM org.apache.aries.spifly.BaseActivator log
> INFO: Registered provider ch.qos.logback.classic.spi.LogbackServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle ch.qos.logback.classic
> 
> * Yes, it is Emacs 29.1.
> 
> * The jdtls logs are a mystery to me. According to https://github.com/eclipse-jdtls/eclipse.jdt.ls/issues/752#issuecomment-412275314,
> 
> "Should be in workspace/.metadata/.log, workspace location is a parameter you pass when starting the server."
> 
> Who is "you"? I suppose the client, i.e. eglot or VS Code. I find files such as
> 
> ./eglot-java-eclipse-jdt-cache/a397d9cc217eb5e87ff722051c2f059b/.metadata/.log
> 
> but they don't contain any info on today's interactions. There is no other directory in that cache. I can tell from that log that the directory was passed as a --data command-line argument. But when I intercept jdtls today via a script to log the command-line args, there is no --data command-line argument passed when invoking jdtls.

João?

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

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66726 <at> debbugs.gnu.org, Cay Horstmann <cay <at> horstmann.com>
Subject: Re: bug#66726: 29.1; Eglot jdtls formatter ignored
Date: Sat, 18 Nov 2023 09:36:01 +0000

On Sat, Nov 18, 2023 at 8:40 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Date: Mon, 6 Nov 2023 18:16:01 +0100
> > From: Cay Horstmann <cay <at> horstmann.com>
> > Cc: 66726 <at> debbugs.gnu.org
> >
> > > Cay, is there some kind of jtdls error log where it reports
> > > things?  Can you also attach the Eglot stderr buffer, in case
> > > it has something useful?  Use `M-x eglot-stderr-buffer`.
> > >
> > > The only thing that seems to be missing is the Emacs version,
> > > but I'll assume it's the version used in M-x report-emacs-bug
> > > itself, which is 29.1.
> > >
> > > João
> >
> > Hello, here is another stab at this.
> >
> > * There is no problem with that funny looking file:/// URL. jdtls can find it when invoked from VS Code and lsp-mode.
> >
> > * I attach the initialization that happens from VS Code. It looks just like the one that I am setting up in eglot. Look at the path initializationOptions.settings.java.format.settings.
> >
> > Formatting works fine in VS Code. The logs show requests such as this one:
> >
> > [Trace - 3:51:32 PM] Sending request 'textDocument/formatting - (71)'.
> > Params: {
> >      "textDocument": {
> >          "uri": "file:///tmp/test/NotHelloWorld.java"
> >      },
> >      "options": {
> >          "tabSize": 4,
> >          "insertSpaces": true
> >      }
> > }
> >
> > These look just like the ones that eglot sends. But the response is a formatting directive that follows the formatter, whereas with eglot, the response is a directive that follows some default.
> >
> > * Here is the requested eglot-stderr-buffer:
> >
> > WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
> > Nov 06, 2023 4:20:36 PM org.apache.aries.spifly.BaseActivator log
> > INFO: Registered provider ch.qos.logback.classic.servlet.LogbackServletContainerInitializer of service jakarta.servlet.ServletContainerInitializer in bundle ch.qos.logback.classic
> > Nov 06, 2023 4:20:36 PM org.apache.aries.spifly.BaseActivator log
> > INFO: Registered provider ch.qos.logback.classic.spi.LogbackServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle ch.qos.logback.classic
> >
> > * Yes, it is Emacs 29.1.
> >
> > * The jdtls logs are a mystery to me. According to https://github.com/eclipse-jdtls/eclipse.jdt.ls/issues/752#issuecomment-412275314,
> >
> > "Should be in workspace/.metadata/.log, workspace location is a parameter you pass when starting the server."
> >
> > Who is "you"? I suppose the client, i.e. eglot or VS Code. I find files such as
> >
> > ./eglot-java-eclipse-jdt-cache/a397d9cc217eb5e87ff722051c2f059b/.metadata/.log
> >
> > but they don't contain any info on today's interactions. There is no other directory in that cache. I can tell from that log that the directory was passed as a --data command-line argument. But when I intercept jdtls today via a script to log the command-line args, there is no --data command-line argument passed when invoking jdtls.
>
> João?

The way I see it, this seems to be mostly a Jdtls problem, with lots
of Java world infrastructure details.

We'd need someone with Elisp and Java expertise (and respective
toolchains) to reproduce this, and I only have the former.

Can, since you do program Java, can you try to attach a debugger
or do some printf debugging or follow the code paths in Jdtls
to see why it  isn't using the "file:///data/cay/bin/cay-eclipse.formatter.xml"
file that (as we've already established) Eglot is sending it
(or at least attempting to send)?

Anway I'll give it a shot using a VM I sed for reproducing a Tramp/Eglot
problem a while ago.  No promises though, the setup overhead
is large here.

João

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

From: Cay Horstmann <cay <at> horstmann.com>
To: João Távora <joaotavora <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 66726 <at> debbugs.gnu.org
Subject: Re: bug#66726: 29.1; Eglot jdtls formatter ignored
Date: Sun, 7 Jan 2024 16:39:56 +0700

On 18/11/2023 16.36, João Távora wrote:
> On Sat, Nov 18, 2023 at 8:40 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>>> Date: Mon, 6 Nov 2023 18:16:01 +0100
>>> From: Cay Horstmann <cay <at> horstmann.com>
>>> Cc: 66726 <at> debbugs.gnu.org
>>>
>>>> Cay, is there some kind of jtdls error log where it reports
>>>> things?  Can you also attach the Eglot stderr buffer, in case
>>>> it has something useful?  Use `M-x eglot-stderr-buffer`.
>>>>
>>>> The only thing that seems to be missing is the Emacs version,
>>>> but I'll assume it's the version used in M-x report-emacs-bug
>>>> itself, which is 29.1.
>>>>
>>>> João
>>>
>>> Hello, here is another stab at this.
>>>
>>> * There is no problem with that funny looking file:/// URL. jdtls can find it when invoked from VS Code and lsp-mode.
>>>
>>> * I attach the initialization that happens from VS Code. It looks just like the one that I am setting up in eglot. Look at the path initializationOptions.settings.java.format.settings.
>>>
>>> Formatting works fine in VS Code. The logs show requests such as this one:
>>>
>>> [Trace - 3:51:32 PM] Sending request 'textDocument/formatting - (71)'.
>>> Params: {
>>>       "textDocument": {
>>>           "uri": "file:///tmp/test/NotHelloWorld.java"
>>>       },
>>>       "options": {
>>>           "tabSize": 4,
>>>           "insertSpaces": true
>>>       }
>>> }
>>>
>>> These look just like the ones that eglot sends. But the response is a formatting directive that follows the formatter, whereas with eglot, the response is a directive that follows some default.
>>>
>>> * Here is the requested eglot-stderr-buffer:
>>>
>>> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
>>> Nov 06, 2023 4:20:36 PM org.apache.aries.spifly.BaseActivator log
>>> INFO: Registered provider ch.qos.logback.classic.servlet.LogbackServletContainerInitializer of service jakarta.servlet.ServletContainerInitializer in bundle ch.qos.logback.classic
>>> Nov 06, 2023 4:20:36 PM org.apache.aries.spifly.BaseActivator log
>>> INFO: Registered provider ch.qos.logback.classic.spi.LogbackServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle ch.qos.logback.classic
>>>
>>> * Yes, it is Emacs 29.1.
>>>
>>> * The jdtls logs are a mystery to me. According to https://github.com/eclipse-jdtls/eclipse.jdt.ls/issues/752#issuecomment-412275314,
>>>
>>> "Should be in workspace/.metadata/.log, workspace location is a parameter you pass when starting the server."
>>>
>>> Who is "you"? I suppose the client, i.e. eglot or VS Code. I find files such as
>>>
>>> ./eglot-java-eclipse-jdt-cache/a397d9cc217eb5e87ff722051c2f059b/.metadata/.log
>>>
>>> but they don't contain any info on today's interactions. There is no other directory in that cache. I can tell from that log that the directory was passed as a --data command-line argument. But when I intercept jdtls today via a script to log the command-line args, there is no --data command-line argument passed when invoking jdtls.
>>
>> João?
> 
> The way I see it, this seems to be mostly a Jdtls problem, with lots
> of Java world infrastructure details.
> 
> We'd need someone with Elisp and Java expertise (and respective
> toolchains) to reproduce this, and I only have the former.
> 
> Can, since you do program Java, can you try to attach a debugger
> or do some printf debugging or follow the code paths in Jdtls
> to see why it  isn't using the "file:///data/cay/bin/cay-eclipse.formatter.xml"
> file that (as we've already established) Eglot is sending it
> (or at least attempting to send)?
> 
> Anway I'll give it a shot using a VM I sed for reproducing a Tramp/Eglot
> problem a while ago.  No promises though, the setup overhead
> is large here.
> 
> João

I was asked to reference the discussion on https://github.com/joaotavora/eglot/discussions/1222#discussioncomment-7683229

I reported that

(remove-hook 'eglot-connect-hook 'eglot-signal-didChangeConfiguration)

makes the formatter work. João Távora commented that this prevents Eglot from atomatically sending project-specific configuration to *any* server.

I am unsure what the effects of that would be, but I gather from João's comment that it is not an acceptable solution.

Cay

-- 

--

Cay S. Horstmann | http://horstmann.com | mailto:cay <at> horstmann.com

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

From: João Távora <joaotavora <at> gmail.com>
To: Cay Horstmann <cay <at> horstmann.com>
Cc: 66726 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#66726: 29.1; Eglot jdtls formatter ignored
Date: Mon, 8 Jan 2024 11:37:57 +0000

On Sun, Jan 7, 2024 at 9:40 AM Cay Horstmann <cay <at> horstmann.com> wrote:

> I was asked to reference the discussion on https://github.com/joaotavora/eglot/discussions/1222#discussioncomment-7683229

Yes, thank you for doing so.

> I reported that
>
> (remove-hook 'eglot-connect-hook 'eglot-signal-didChangeConfiguration)
>
> makes the formatter work. João Távora commented that this prevents Eglot from atomatically sending project-specific configuration to *any* server.
>
> I am unsure what the effects of that would be, but I gather from João's comment that it is not an acceptable solution.

It might not be acceptable for all users, yes.  It may be acceptable for you.

Here's a summary of this issue as I understand it:

1. jdtls's support for custom formatters can be achieved by passing suitable
   LSP :initializationOptions

2. According to you, jtdls's support for custom formatters _cannot_
   be achieved with LSP workspaceConfiguration.  It _has_ to use 1.

3. In jdtls, a blank LSP workspaceConfiguration request overwrites any
   settings passed in LSP initializationOptions.  This was confirmed
   by more than one user, I think.

2 and 3 dictate that, barring any changes on the jdtls side, the only
way to use custom formatters in Eglot is for Eglot to not send
LSP workspaceConfiguration to this server at all.  Has jdtls been made
aware of this conflict between 2 and 3?

You may also want to try the less intrusive:

(add-hook 'java-mode-hook (lambda ()
   (remove-hook 'eglot-connect-hook 'eglot-signal-didChangeConfiguration t))

To do it just for java-mode.  If you're using java-ts-mode, you need a similar
incantation, unless some java-base-mode exists (it exists for some Emacs
modes, not sure if Java)

João

Previous Next

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