From: "João Távora" <joaotavora@gmail.com>
To: Danny Freeman <danny@dfreeman.email>, dgutov@yandex.ru
Cc: 58790@debbugs.gnu.org, Stefan Kangas <stefankangas@gmail.com>
Subject: bug#58790: Eglot URI parsing bug when using clojure-lsp server
Date: Thu, 27 Oct 2022 16:09:18 +0100 [thread overview]
Message-ID: <87ilk5xq01.fsf@gmail.com> (raw)
In-Reply-To: <8cf8ba5d-c604-b2dc-274a-7597b19fb73f@dfreeman.email> (Danny Freeman's message of "Wed, 26 Oct 2022 15:50:02 -0400")
Danny Freeman <danny@dfreeman.email> writes:
> Danny: The patches would still be necessary. The patches simply make
> eglot Danny: correctly parse the "jar:" scheme URIs from lsp servers
> that use them. Danny: It doesn't have much to do with how emacs is
> handling the file paths Danny: once it is parsed.
Indeed, I am in agreement with the last sentence. And this means the
result of this parsing is arbitrary as long as it's a bijection.
>> In my mind, project.el should support adding jars as collections of
>> source files just like it supports adding directories as collections
>> of source files. Many years ago, Eclipse did this. You could add a jar
>> as a library or a file as a library: it's just a different
>> implementation detail.
>
> Danny: Maybe so, it's unclear in my mind how that would work with lsp
> Danny: servers.
Here's how I envision it working, from reading some of the source
involved, but with no testing:
1. In buffer B1, the user uses M-. (xref-find-definition). Eglot
requests :textDocument/definition from the LSP server, which returns
a number of definitions. Some of these look like
jar:file:///home/user/.m2/repository/org/clojure/clojure/1.10.3/clojure-1.10.3.jar!clojure/core.clj
Call this value X.
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.
We'll see later if and how eglot--uri-to-path needs to be changed to
do this conversion in a way that doesn't hurt all the other
conversions it already does there. One of the possibilities is just
to leave X completely untouched and pass it onwards.
The word "path" in eglot--uri-to-path should be understood as "file
name" or "file designator" (depending on whether you are into Elisp
or CL parlance). It does not necessarily represent a filesystem
path. eglot--uri-to-path should probably be renamed, but that is a
cosmetic tweak.
3. Using xref--show-location on one of these matches will eventually
call xref-location-marker and invoke invoke find-file-noselect on Y.
Here, an entry of file-name-handler-alist should know how to handle the
format Y. This is what Danny is working on as a separate package.
If that entry exists, the process should land the user in some buffer
B2 where buffer-file-name is set to Y.
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.
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.
I don't understand that "vc" has to do with this. The above
implementation should work with any project backend, not just VC.
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.
> 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.
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.
Or maybe I'm misunderstanding the whole flow, or missing some detail, in
which case feel free to correct me.
> Danny: Without the files being extracted somewhere would they be able to
> Danny: perform any analysis on them?
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.
João
next prev parent reply other threads:[~2022-10-27 15:09 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 21:44 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
2022-10-26 6:22 ` Stefan Kangas
2022-10-26 19:50 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-27 15:09 ` João Távora [this message]
2022-10-29 1:22 ` Dmitry Gutov
2022-10-29 2:02 ` João Távora
2022-10-29 14:54 ` Dmitry Gutov
2022-10-29 19:35 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-31 14:40 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-02 8:09 ` João Távora
2022-11-02 13:15 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-03 17:10 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-10 9:49 ` Eli Zaretskii
2022-11-10 11:00 ` João Távora
2022-11-10 13:47 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-10 15:38 ` Eli Zaretskii
2022-11-10 21:45 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-10 21:59 ` João Távora
2022-11-10 22:22 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-10 22:30 ` João Távora
2022-11-10 22:48 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-10 22:48 ` João Távora
2022-11-10 22:57 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-11 7:29 ` Eli Zaretskii
2022-11-12 17:03 ` Michael Albinus
2022-11-13 21:04 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-15 19:04 ` Michael Albinus
2022-11-15 22:28 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-16 7:53 ` Michael Albinus
2022-11-16 10:21 ` João Távora
2022-11-16 15:45 ` Michael Albinus
2022-11-16 16:20 ` João Távora
2022-11-16 22:59 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-02 16:14 ` Michael Albinus
2022-12-07 18:56 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-08 13:46 ` Michael Albinus
2022-12-08 19:07 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-09 16:04 ` Michael Albinus
2022-12-10 17:21 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-10 17:45 ` Michael Albinus
2022-11-22 14:30 ` Michael Albinus
2022-11-23 11:55 ` Richard Copley
2022-11-23 12:36 ` João Távora
2022-11-23 12:42 ` Arash Esbati
2022-11-23 12:49 ` Richard Copley
2022-11-23 12:54 ` João Távora
2022-11-23 13:33 ` Eli Zaretskii
2022-11-23 13:44 ` João Távora
2022-11-23 14:03 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-23 19:53 ` João Távora
2022-11-11 8:30 ` Eli Zaretskii
2022-11-11 9:45 ` João Távora
2022-11-11 12:01 ` Eli Zaretskii
2022-11-11 14:02 ` João Távora
2022-11-11 14:45 ` Eli Zaretskii
2022-11-12 9:04 ` João Távora
2022-11-11 7:16 ` Eli Zaretskii
2022-11-01 17:25 ` Juri Linkov
2022-10-29 15:36 ` Felician Nemeth
2022-10-29 17:09 ` João Távora
2022-11-09 0:59 ` bug#58790: Robert Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ilk5xq01.fsf@gmail.com \
--to=joaotavora@gmail.com \
--cc=58790@debbugs.gnu.org \
--cc=danny@dfreeman.email \
--cc=dgutov@yandex.ru \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).