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

Previous Next

Full log

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?

Previous Next

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