From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Danny Freeman via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#58790: Eglot URI parsing bug when using clojure-lsp server Date: Wed, 02 Nov 2022 09:15:36 -0400 Message-ID: <877d0do5sp.fsf@dfreeman.email> 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> <87v8nxsrq6.fsf@gmail.com> Reply-To: Danny Freeman 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="33032"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58790@debbugs.gnu.org, felician.nemeth@gmail.com, Stefan Kangas , Dmitry Gutov To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 02 14:17:56 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 1oqDct-0008Bj-4R for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Nov 2022 14:17:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqDcG-0006ew-3l; Wed, 02 Nov 2022 09:17:12 -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 1oqDc6-0006e5-VM for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 09:17:06 -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 1oqDc6-0002Zl-Nw for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 09:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oqDc6-0004Ax-70 for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 09:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Danny Freeman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Nov 2022 13:17:02 +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.166739499116010 (code B ref 58790); Wed, 02 Nov 2022 13:17:02 +0000 Original-Received: (at 58790) by debbugs.gnu.org; 2 Nov 2022 13:16:31 +0000 Original-Received: from localhost ([127.0.0.1]:45177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqDba-0004AA-VK for submit@debbugs.gnu.org; Wed, 02 Nov 2022 09:16:31 -0400 Original-Received: from out2.migadu.com ([188.165.223.204]:60643) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqDbX-00049y-Oy for 58790@debbugs.gnu.org; Wed, 02 Nov 2022 09:16:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dfreeman.email; s=key1; t=1667394986; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GO7H5nQc9n795pFnlt3ByluTzCxSCqDF6T2ggyxaazM=; b=EkzVpHM2KB69Uzgxibl7xKVYcq9buhRdQjBBCq+RsmK+hXoSygyTX09IylTuJlMkwOO4rd VCdf1565cX08nccuwlsz8f4h1qIN0Rolwkavjzhy59ZaNcvUmpLLNIdMC9IkRDgyA/ssMd w0sL0D463eSnf1XhzMnt55seE7w3lR4= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. In-reply-to: <87v8nxsrq6.fsf@gmail.com> X-Migadu-Flow: FLOW_OUT 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:246867 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > 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 '(("vs= code-html-language-server" "--stdio") ("html-languageserver" "--stdio")))) > (dockerfile-mode . ("docker-langserver" = "--stdio")) > ((clojure-mode clojurescript-mode clojur= ec-mode) > - . ("clojure-lsp")) > + . ("clojure-lsp" :initializationOptions= (:dependency-scheme "jar"))) > (csharp-mode . ("omnisharp" "-lsp")) > (purescript-mode . ("purescript-language= -server" "--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? "jar" is not the default, "zipfile" is. The clojure-lsp maintainers want to make jar the default but have not pulled the trigger on that yet. Other lsp clients seem to be forcing "jar" in the initialization options as well. If we don't force it then I would be getting zipfile URIs, which is not the end of the world, but I would prefer to only deal with the scheme that the clojure-lsp devs want to use going forward. I could either set the jar initialization option myself, tell the user to, or also support the zipfile scheme. Setting it here is seems to be the easiest thing. Including it does not have any downsides that I know of. Either way, without some special file-name-handler dependencies in jars returned by clojure-lsp cannot be opened. The end result is the same empty buffer. > +(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. This makes sense and seems very reasonable to me. I will send an updated patch that tries to do this. One question I have is, does it make sense to still parse the escape sequences (via url-unhex-string) in the full URI? Or do we continue to leave it as is? In my local testing I've left it as is but don't have any jars that I can navigate to with special characters in the path. > Felici=C3=A1n also suggested that Eglot warns the user when it doesn't kn= ow > 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. I think it would be pretty straight forward to see if something like `find-file-name-handler` would pick up an unaltered URI for a common operation that we know eglot will be using, like `expand-file-name`. If it doesn't then a warning can be issued.