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

[Dmitry Gutov]

On 27.10.2022 18:09, João Távora wrote:

> 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.

This point seems to be key, to be able to continue 'M-.' from inside the 
jar.

> 5. Upon findin the "file", Eglot transmits a :textDocument/didOpen
>     notification to the server.  This requires eglot--path-to-uri, the
>     reciprocal of eglot--uri-to-path to convert the path Y to URI X
>     again.  Again, maybe this conversion is just #'identity.
>
>     Eventually, the LSP server knows that the client is now working on a
>     textDocument whose relationship to other opened documents in the
>     workspace it understands (which may or may not be read-only).
>
> 6. xref-find-definition on any part of the B2 should now work similarly
>     to this whole flow.
>
> > Dmitry: Sounds like you want to advise project-vc-external-roots-function. Or
> > Dmitry: change its whole value.

FWIW, project-external-roots might be a red herring for this discussion. 
I just saw somebody mention project-external-roots, and the above would 
be a way to add to that list.

> I don't understand that "vc" has to do with this.  The above
> implementation should work with any project backend, not just VC.

Okay...

> To be clear, my suggestion was to add the ability to add a jar file to
> project-external-roots.  Currently a root is a string representing a
> directory, per its docstring.  But it could be generalized to a string
> representing any container of files.

Container or not, the return value of project-external-roots, just like 
that of project-root, is determined by the project backend, its internal 
structures, and how it is customized by the user.

We don't provide a setter for 'project-root', so I don't understand the 
expectation of being able to modify project-external-roots for an 
arbitrary project type either.

> > Dmitry: Or create an Eglot-specific project backend.
>
> I don't understand this suggestion either.  Normally Eglot is a client
> of project information maintained by other project.el backends.  Very
> commonly VC projects, but not always necessarily so.  That clashes with
> the idea of making Eglot simultaneously a supplier of this information.

There is indeed certain tension, but if Eglot wants to decide stuff 
about the project (which, as I said in the past, could be a reasonable 
idea), then it could provide its own project backend. We're not 
necessarily at that point, though, because...

> Please read the summary of the outlined above.  Maybe there's nothing to
> be done in project.el if eglot-extend-to-xref is to be used.

...indeed you could stop at that.

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.

But as for xref-find-definitions, item 4 in your list should be enough 
(with either of the alternatives as underlying implementation).