bug#58790: Eglot URI parsing bug when using clojure-lsp server

[Danny Freeman via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

[-- Attachment #1.1.1: Type: text/plain, Size: 4336 bytes --]

 > 2. Eglot converts the URI X into a some file designator Y, using
 >   eglot--uri-to-path.  Y may or may not be === X, as long as there is
 >   exactly one X for every Y.  Eglot makes xref-item objects from it
 >   using xref-make-match and xref-make-file-location.  The designator Y
 >   goes into the 'file' slot of the xref-file-location object.

I will look into seeing if everything can work where Y === X. What this 
means
is that the X will start with `jar:file://`, and the last time I attempted I
had to re-implement all of the file-name-handler-alist operations (there 
are a
LOT). I am not sure why stripping the URI information off made this not
necessary but it sure makes the implement a lot simpler. I still don't fully
understand why, but that is alright. It's just going to take me some time.

 > 4. B2 can be setup in a way so that project-current returns the same
 >    object which is returned in B.  If this is true,
 >    eglot--current-server discovers the same connection which also
 >    manages B1 and Eglot adds buffer B2 to the list of managed buffers in
 >    that connection.
 >
 >    However, if eglot-extend-to-xref is non-nil, eglot--current-server
 >    should also discover the correct connection.  This is less ideal than
 >    making project-current know that the buffers of source code inside
 >    the jar are also in the same project, but it works.  I can explain
 >    the downsides, but it's not very relevant right now.

Depending on the implementation of my file-name-handler-alist function, I
think my only option is to make project-current return the project of buffer
B. NOT doing this results in `eglot-current-server` returning a transient
project, I believe from `eglot--curent-project`, causing a new server to be
started by eglot. I need to spend some more time with this code as well to
make sure I understand how this is being triggered, but it probably 
comes from
my abuse of the file-name-handler-alist.

 > Maybe Eglot just needs to be changed to _not_ strip the leading
 > "jar:file" and leave it completely unchanged.

 > So the server should be able to sort itself out, as long as you give
 > back the very same URI you got -- from the server itself -- to the
 > in-JAR source code.

I hope this is the case. I guess it depends on the lsp server's
implementation. In the case of clojure-lsp, and probably other jvm 
languages I
suspect that it would automatically understand `jar:` URIs.

...

 > The downside is that once a system file discovered by the LSP server, it
 > is associated with a given server (_not project_) in Eglot.  I don't
 > know what happens if another server also points to the same file.
 > Probably nothing very bad, but there may be some suprising behavior: I
 > haven't tested.


 > > Having the jars in project-external-roots could enable the users
 > > (after certain integration work) to search across their contents with
 > > project-or-external-find-regexp, or jump to files inside with
 > > project-or-external-find-file.
 >
 > That's a very nice point.  I don't use Java fortunately, but when I did
 > a long time ago, I think I remember Eclipse let me do this.

That might be nice. I think we would have to just extract the jar 
contents at
that point and use that. Not quite sure.

 > Okay: some new project type. Or a new feature that parses build 
files. Or etc. All of that could be reasonable, but is yet for somebody 
to design and implement.
 >
 > IMHO a feature that takes up the goal of providing comprehensive IDE 
support could take up that responsibility too. But I'm fine either way.
 >
 > That would also depend on whether the LSP protocol is ever going to 
be extended toward providing build file information, running build 
tasks, etc.

That I think this goes beyond the scope of what I want to do, and have the
ability to do. This is encroaching into cider's responsibilities I think. It
provides the full IDE expereince, and does so at the heavyweight cost of
running the actual project.

Thank you both for the input. It's given me a _lot_ to think about and
experiment with. It will probably take me some time to work through these
problems considering my day job and baby. Forgive me if it takes some 
time for
me to respond.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3185 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]