bug#66726: 29.1; Eglot jdtls formatter ignored

[João Távora]

On Sat, Nov 18, 2023 at 8:40 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Mon, 6 Nov 2023 18:16:01 +0100
> > From: Cay Horstmann <cay@horstmann.com>
> > Cc: 66726@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