bug#61371: 30.0.50; Adding support for jdt:// file scheme in eglot

[Danny Freeman]

Danny Freeman <danny@dfreeman.email> writes:

> Theodor Thornhill <theo@thornhill.no> writes:
>
>> Michael Albinus <michael.albinus@gmx.de> writes:
>>
>>> Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife
>>> of text editors" <bug-gnu-emacs@gnu.org> writes:
>>>
>>>> Hi!
>>>
>>> Hi Theo,
>>>
>>>> When using Eglot along with Java there are some hacks that needs to be
>>>> made to make things functional.  One of the more important things is to
>>>> add support for the jdt:// file scheme that is sent when you try to
>>>> go-to-definition on a system or third party lib.
>>>>
>>>> As you can see, we need to query the server with
>>>> :java/classFileContents, and also register with the server to send it
>>>> with the :extendedClientCapabilities on initialization.
>>>>
>>>> Is there a place this code could live? Maybe in the new java-ts-mode?
>>>
>>> There is the jarchive package on GNU ELPA. Could this be used, perhaps 
>>> extended?
>>>
>>>> Theo
>>>
>>> Best regards, Michael.
>>
>> Maybe! Don't know what it does, but I'll check it out - thanks!
>>
>> Theo
>
> JDT urls are outside the scope of jarchive. I would think of them less
> as URLs and more as tokens to be decoded by the LSP server that provides
> them. JDT urls are intended to be sent back to the LSP server using a
> special extension method.
>
> There is an issue open in the eglot-java repo to implement this but I
> have been too busy to get around to it
> https://github.com/yveszoundi/eglot-java/issues/6
>
> Someone has responded there with some code similar to jarchive that will
> parse the JDT urls and try to open them, but I wouldn't consider that a
> permanent solution. JDT urls are not standardized and subject to change
> by the JDT LSP maintainers.

I think this bug can be closed now, it was fixed in the eglot-java
package. See: https://github.com/yveszoundi/eglot-java/issues/6

Thank you,
-- 
Danny Freeman