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: Thu, 27 Oct 2022 16:09:18 +0100 Message-ID: <87ilk5xq01.fsf@gmail.com> References: <8cf8ba5d-c604-b2dc-274a-7597b19fb73f@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="34089"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 58790@debbugs.gnu.org, Stefan Kangas To: Danny Freeman , dgutov@yandex.ru Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 27 17:09:32 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 1oo4Vb-0008U6-Sg for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 27 Oct 2022 17:09:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oo4VE-0002Xn-Vx; Thu, 27 Oct 2022 11:09:05 -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 1oo4VC-0002Dv-NA for bug-gnu-emacs@gnu.org; Thu, 27 Oct 2022 11:09:02 -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 1oo4VC-0001dp-FJ for bug-gnu-emacs@gnu.org; Thu, 27 Oct 2022 11:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oo4VC-00061h-1X for bug-gnu-emacs@gnu.org; Thu, 27 Oct 2022 11:09:02 -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: Thu, 27 Oct 2022 15: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.166688330123104 (code B ref 58790); Thu, 27 Oct 2022 15:09:01 +0000 Original-Received: (at 58790) by debbugs.gnu.org; 27 Oct 2022 15:08:21 +0000 Original-Received: from localhost ([127.0.0.1]:58950 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oo4UU-00060X-80 for submit@debbugs.gnu.org; Thu, 27 Oct 2022 11:08:21 -0400 Original-Received: from mail-wr1-f45.google.com ([209.85.221.45]:46886) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oo4US-00060E-5r for 58790@debbugs.gnu.org; Thu, 27 Oct 2022 11:08:16 -0400 Original-Received: by mail-wr1-f45.google.com with SMTP id bk15so2639164wrb.13 for <58790@debbugs.gnu.org>; Thu, 27 Oct 2022 08:08:16 -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=N6WJwSGNaHeYY35i/+rGqg2ph3Xb9Ay7ZZsnEYSE780=; b=UOFLReEj032rGkTStwM/z7NzRUVk4JAD+CWzPOUZigyG0rGKmvw2dg+2/Y8Pzu7cfl XKzH3LM0bmpolhC3XYZjz8Ry2Plsuiz5G6dtGDH3jhGfRrgJZRuy6FKfs5W6mdI7VhI5 wfDEd1F8b/CEq8Gfi2vs4AEo2yO+iigk1PLWSPNnzBYOHL5tkRfXxIiSr/gHCyI9tdb+ EK5FZ0DTWcFmkspKu+wtS3YPfV0b9kYKpbDWkT6S6np/Hq8X/hRZM9vBPy8051gOZ1i4 ZN6DMtDbftSO2ztWAmgzyBnBtkVZ64dOmfGrenxWJiHgWvmtMHKk/ReWebYtRDigvEUo WRcg== 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=N6WJwSGNaHeYY35i/+rGqg2ph3Xb9Ay7ZZsnEYSE780=; b=t1JGBfWKUutAVOlhio4XIeh2nR+wS3qDkox6OlKWApVoiwsdSlQqjZBGBDFTKL/s/C /MWanRmUqtwUVfItWjt0dwbUuFUT+JSsYGKmFhes7P9Z31+yEyg3rhr/XUtznaLPTY8C mkOKkCwIR0fxaMcXkWQ7kdCS9+IcLaJhac5YBPL2A4lcIoUrlJJTNVHuaeIubBcZWQaB gyBsRf16RX8C9Jmnos028tFeIRGKeHz7lYkody/ENp7pxfiv4UDAAHvngLvb/a8q9JXH DfL2ChCHT2Qo59C+9D/FFyB2bzYic+M1Bln/lWcRj1HDZFx44bKOEgUrWFGamrO3XNQs JXxg== X-Gm-Message-State: ACrzQf2lwJMGi0hTU+j1fdDO3QwUW4vH2OzBGM1Iud4uZBzsMGgz3cRQ 4AmC+9E7XoFYrXDFPT1j5C374HZMN44= X-Google-Smtp-Source: AMsMyM6TBgzwtPANTEAGmr2uMswAAWZ7k3TiBwiTE4NhXQ21dknFiv2aVfhdGo0/JPbqBxEpY2GPcQ== X-Received: by 2002:a05:6000:1e0b:b0:236:8a6e:8d with SMTP id bj11-20020a0560001e0b00b002368a6e008dmr6042052wrb.20.1666883289794; Thu, 27 Oct 2022 08:08:09 -0700 (PDT) Original-Received: from krug ([87.196.73.148]) by smtp.gmail.com with ESMTPSA id l3-20020a05600c4f0300b003a5f3f5883dsm5461399wmq.17.2022.10.27.08.08.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Oct 2022 08:08:08 -0700 (PDT) In-Reply-To: <8cf8ba5d-c604-b2dc-274a-7597b19fb73f@dfreeman.email> (Danny Freeman's message of "Wed, 26 Oct 2022 15:50:02 -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:246308 Archived-At: Danny Freeman 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/clojur= e-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 =3D=3D=3D 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. =20=20=20 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=C3=A3o