From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#58790: Eglot URI parsing bug when using clojure-lsp server Date: Wed, 02 Nov 2022 08:09:05 +0000 Message-ID: <87v8nxsrq6.fsf@gmail.com> References: <8cf8ba5d-c604-b2dc-274a-7597b19fb73f@dfreeman.email> <87ilk5xq01.fsf@gmail.com> <87r0yrwfn3.fsf@gmail.com> <37716e41-5955-99f6-5204-e760a716fbf6@yandex.ru> <9bb290c8-f000-31d8-265d-b5441c33eb38@dfreeman.email> <4d50b820-7053-75eb-5b11-d3d36a02b013@dfreeman.email> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30013"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 58790@debbugs.gnu.org, felician.nemeth@gmail.com, Stefan Kangas , Dmitry Gutov To: Danny Freeman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 02 09:09:43 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oq8og-0007cq-Q2 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Nov 2022 09:09:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oq8oS-0006uG-0L; Wed, 02 Nov 2022 04:09:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oq8o2-0006hK-5V for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 04:09:13 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oq8o1-00043R-SG for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 04:09:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oq8o1-00021w-IE for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 04:09:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Nov 2022 08:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58790 X-GNU-PR-Package: emacs Original-Received: via spool by 58790-submit@debbugs.gnu.org id=B58790.16673765047761 (code B ref 58790); Wed, 02 Nov 2022 08:09:01 +0000 Original-Received: (at 58790) by debbugs.gnu.org; 2 Nov 2022 08:08:24 +0000 Original-Received: from localhost ([127.0.0.1]:44860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oq8nQ-000216-9I for submit@debbugs.gnu.org; Wed, 02 Nov 2022 04:08:24 -0400 Original-Received: from mail-wr1-f54.google.com ([209.85.221.54]:45002) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oq8nO-00020s-5C for 58790@debbugs.gnu.org; Wed, 02 Nov 2022 04:08:23 -0400 Original-Received: by mail-wr1-f54.google.com with SMTP id v1so23285440wrt.11 for <58790@debbugs.gnu.org>; Wed, 02 Nov 2022 01:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=DXpvfkQnHfay6Z7KUCZr0AjrF6jnC6R5QChT+j2cS/I=; b=GI3C3zadwsVryBwDGdAbu1yf6sPlFhtXcL/f35p2y/qiA9AsJWGkblZ9/vzVm3Yn9n 5UbheP/HIxKcetK70lQPm8IcH+YIafVAAqPOtDZB3F2vrdhinj9pDbmcXViOZB4W846+ GRTAZKpaHf27LluiapbbdoYj3WIEDvjELF4fGY/DiyNKdWJ2EZhtcnbMFf01BjUSNUZt oXJ10Pz9aRkZFQkKO3ofKCk8q/sYtJUOglB+Jk7wCpc0MYBWMee/rpe5Z6Qvt7avnXJc ULaieaJ4YhHmXUZsj6AcIS6l/YgbZRhYxStabUt0TjfC2ensede5S3quIZOuoBcsUy7r lXWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=DXpvfkQnHfay6Z7KUCZr0AjrF6jnC6R5QChT+j2cS/I=; b=wsA/OdoD1jTWLnjj88D0TvgPaPiRXV/hlF8s0CiDyhuPhdtFXhSawafWHg0AuIyT1j QfsuAg7afg/8GJ9DfXxhDxDNlKRw8vIcgJK59sjKMWYtfyiZKV5wD/JcwS4kHOKfVT5Y /jy+UGWlYK08nuPCFaubGblgK6P20+0fcbiKtDlBokbbZOMC8CwXa3GCA5NqSBuSQ1Ee vn84QkOzQzXz2raEbVhUydZhoZQTxf0gzUAVlS96kUfQ4v3QKcxi20VREFKfzcLjXUGg dxuxy0I0pmDAaf/FhG1tGIh2uMmKKMrW0n4IrrTNp/RzGM2K7wC7ToweUVAQn9Tdr87e LhwQ== X-Gm-Message-State: ACrzQf3dMwVPFRNqQV6Su6p9cYN98zZUjMfhuQ7dzj6O3I/8ekyu2lTq BjuXkO21y2f05WNDxeHyx2w= X-Google-Smtp-Source: AMsMyM7oIkoLaubdiYzbFBZ2jFNzzGr+rmiwfUKVAnIeOd4gTPb5ph8HSm8a4EwxxYp4+JhVzv7VcA== X-Received: by 2002:a05:6000:156e:b0:236:ed91:5354 with SMTP id 14-20020a056000156e00b00236ed915354mr1638651wrz.203.1667376496478; Wed, 02 Nov 2022 01:08:16 -0700 (PDT) Original-Received: from krug ([87.196.81.36]) by smtp.gmail.com with ESMTPSA id p7-20020a05600c430700b003b31c560a0csm1168461wme.12.2022.11.02.01.07.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Nov 2022 01:08:16 -0700 (PDT) In-Reply-To: <4d50b820-7053-75eb-5b11-d3d36a02b013@dfreeman.email> (Danny Freeman's message of "Mon, 31 Oct 2022 10:40:22 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246847 Archived-At: Danny Freeman writes: > I have a new patch attached that does what Jo=C3=A3o suggested in the 5 > point list, > which I will respond to again > >> 2. Eglot converts the URI X into a some file designator Y, using >> eglot--uri-to-path. Y may or may not be =3D=3D=3D X, as long as ther= e 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. > > The patch leaves X =3D=3D=3D Y for `jar` type URIs. My updated packages n= ow > deals with > the full jar URIs. No conversion are done. My new package can be found he= re: > https://git.sr.ht/~dannyfreeman/jarchive/tree/9148ed7ada03ff2516f6e4ede20= c453974d6da19/item/jarchive.el Cool, I had a brief look, and it looks pretty reasonable. There are indeed many operations, but most of them seem trivial. If you're bothered by the repetitive structure, you can probably use sth like cl-case or pcase to cut down a bit. >> 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). > > Sending the full jar uri back to the lsp server worked exactly as > intended here. Nice. >> 6. xref-find-definition on any part of the B2 should now work similarly >> to this whole flow. > > It does!!!!! Double nice. > As for this question > >> 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. > > The same file continues to work with respect to the original lsp server > that was used to open it. The second lsp server is not conidered. I > guess because eglot can only work with one lsp server at a time. If > you want to > associate the un-jar'd file with the second server, close it and > xref-find-defintions to it from a file in the second server. That > seems like a > fine workaround to me, and its not something I've ever encountered in > my routine > development workflow. This isn't specific to clojure. I don't think it's a big issue: noone has complained and your description of how it works suggests that it doesn't do anything exceptionally silly. > So, what do yall think about the patch? Is that something you might > consider for > eglot? I believe I could also accomplish something similar with > "advice" in my > package and leave eglot alone, but I would be poking at eglot > internals which > seems not ideal. Yes, a patch is in order. Comments below: diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index c587061837..b8f50e3cd8 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -231,7 +231,7 @@ eglot-server-programs (html-mode . ,(eglot-alternatives '(("vsco= de-html-language-server" "--stdio") ("html-languageserver" "--stdio")))) (dockerfile-mode . ("docker-langserver" "-= -stdio")) ((clojure-mode clojurescript-mode clojurec= -mode) - . ("clojure-lsp")) + . ("clojure-lsp" :initializationOptions (= :dependency-scheme "jar"))) (csharp-mode . ("omnisharp" "-lsp")) (purescript-mode . ("purescript-language-s= erver" "--stdio")) (perl-mode . ("perl" "-MPerl::LanguageServer" "-e" "Perl::LanguageServer::run")) Didn't you say that "jar" is already the default for clojure-lsp? Do we really need to force it? What can happen if we don't? +(defvar eglot-preserve-jar-uri nil + "If non-nil, jar: type URIs will not be converted to paths. +This means they will be provided to xref as URIs and not file paths.") We don't need this variable. Eglot should no nothing about jars (except perhaps in only place where "clojure" is mentioned, which is in eglot-server-programs). I think it's better to patch eglot--uri-to-path so that if X looks anything other than file://, Eglot leaves it untouched. After all, it's the only safe translation Eglot can make. And in eglot--path-to-uri, we do likewise. If the PATH argument already looks vaguely URIish (say, it makes something like "^[[:alnum:]]+://") we leave it unchanged. Let me know if that makes sense and you can implement it, else I'll try it myself. Felici=C3=A1n also suggested that Eglot warns the user when it doesn't know an URI scheme. I think that can make sense in some situations, for now let's assume it isn't as important as getting your new Jar file-name-handler to integrate with Eglot. Maybe in some later patch Eglot can somehow predict if there is a file-name-handler entry for a given URI and only warn if there isn't. Jo=C3=A3o