GNU bug report logs -
#58790
Eglot URI parsing bug when using clojure-lsp server
Previous Next
Full log
Message #17 received at 58790 <at> debbugs.gnu.org (full text, mbox):
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).
This bug report was last modified 2 years and 166 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.