bug#66726: 29.1; Eglot jdtls formatter ignored

[Cay Horstmann <cay@horstmann.com>]

On 18/11/2023 16.36, João Távora wrote:
> 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

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@horstmann.com