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: Sat, 29 Oct 2022 03:02:56 +0100 Message-ID: <87r0yrwfn3.fsf@gmail.com> References: <8cf8ba5d-c604-b2dc-274a-7597b19fb73f@dfreeman.email> <87ilk5xq01.fsf@gmail.com> 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="5451"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 58790@debbugs.gnu.org, Stefan Kangas , Danny Freeman To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 29 04:02:48 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 1oobBQ-0001HN-L5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Oct 2022 04:02:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oobAh-0000E7-RY; Fri, 28 Oct 2022 22:02:03 -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 1oobAg-0000Cs-Ht for bug-gnu-emacs@gnu.org; Fri, 28 Oct 2022 22:02: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 1oobAg-0002fU-9l for bug-gnu-emacs@gnu.org; Fri, 28 Oct 2022 22:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oobAf-0001nW-Sv for bug-gnu-emacs@gnu.org; Fri, 28 Oct 2022 22:02: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: Sat, 29 Oct 2022 02:02: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.16670089166897 (code B ref 58790); Sat, 29 Oct 2022 02:02:01 +0000 Original-Received: (at 58790) by debbugs.gnu.org; 29 Oct 2022 02:01:56 +0000 Original-Received: from localhost ([127.0.0.1]:34645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oobAZ-0001nB-IM for submit@debbugs.gnu.org; Fri, 28 Oct 2022 22:01:56 -0400 Original-Received: from mail-wr1-f52.google.com ([209.85.221.52]:38474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oobAX-0001mw-WE for 58790@debbugs.gnu.org; Fri, 28 Oct 2022 22:01:54 -0400 Original-Received: by mail-wr1-f52.google.com with SMTP id a14so8707918wru.5 for <58790@debbugs.gnu.org>; Fri, 28 Oct 2022 19:01:53 -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=k6D+aMLmo3F1em4O1Frs1910+vtqTiHvqTu2QcDrGPE=; b=CFKJyjwgEG7ChGewlIrs8Lf/dDKopyeoNeWcq1ReBzucDPSsmGRbKhD5W3Gnre3lC5 FqnsGbGlAzaVM76BjpuLOCg9XJqbWrTo1ARj93UuTnZf9U/oi8xLvJdoErezeCWiSSyR 1rxG1y81LXkiRAGZFLXpQcDbeuWsq//SOtSuXahn5yJzG9E4zQT1wxXC+B/I5jlSXn9l uAUV12d8Ad6z8ZULvv1XSWQ9/3GSLmU8Q87Kf6Eprg4xduf6af73lSO9ItDE5ZJE/QGt FCortUmmamxdE/XAdo6OSFjE+OOgjDHHbsCml4i5iqcu/GvknNr58fhMi1VIStpZFoUY i7oA== 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=k6D+aMLmo3F1em4O1Frs1910+vtqTiHvqTu2QcDrGPE=; b=E6/SC1XdMWZLiam38UYSfWn+Ca2H1kFHGR4topdYHGi/sG2p443lC0v844K27UYSvz ralEKFdyei7rJx7R83zSeB+c4tee7sLUskxyf/jOPVghb03W5EkkaoaPPZKIgF2+yBWE hEYpQXXf+DBSot2puUNN46lKpanwI+YO/VoS0HLbAXneh5ITR3w5AzcUTC7zsSV1sI25 dw/jGXkQ3VtsgJTvvZ1Uj5sZnGw+cgGXHFZ3B6G+Yby5APyCj1asztjVjHxFGgu6aReA z38kd/NNGUCxDYOUZILDqzxViroqP4KV575t+NrBAnRxO/nCcjmV4G5lbM0/aHt0cgO+ 6EVQ== X-Gm-Message-State: ACrzQf3qo5EDML3aL/x5Q+PUdo/LS+6ZQvW/DI9ePAhE3Qaekdegxe1D IKrv/iD4GFYz3GFRVz8rKJo= X-Google-Smtp-Source: AMsMyM5u00U/fmvjC5KKWd5gafxAZueoCNFahrUoFMcMJ+Mjj2u6TbNxWOC2D/275L1u8ju905XlIg== X-Received: by 2002:a5d:59a5:0:b0:236:8d38:4f1d with SMTP id p5-20020a5d59a5000000b002368d384f1dmr1113013wrr.131.1667008907632; Fri, 28 Oct 2022 19:01:47 -0700 (PDT) Original-Received: from krug (87-196-74-89.net.novis.pt. [87.196.74.89]) by smtp.gmail.com with ESMTPSA id v23-20020a05600c215700b003c5571c27a1sm217376wml.32.2022.10.28.19.01.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Oct 2022 19:01:46 -0700 (PDT) In-Reply-To: (Dmitry Gutov's message of "Sat, 29 Oct 2022 04:22:43 +0300") 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:246474 Archived-At: Dmitry Gutov writes: > 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. I think I understand your confusion. I'm not suggesting that Eglot modifies it. I'll explain better below. >>> 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... Eglot doesn't want to decide anything about project. Eglot justs wants to go into user visible projects and answer the question: (project-current). It wants this because it maps project/major-mode pairs to server connections.=20 Eglot doesn't care if the project is of type 'vc, 'transient, 'visual-studio-solution-file, 'joes-complicated-project, etc.=20=20 So Eglot providing a project backend doesn't make sense. Maybe you think I'm suggesting that Eglot that could collect these references to jars coming from the LSP server and add them to project-external-roots somehow. I'm not suggesting that.=20=20 It's just that an arbitrary project backend, other than 'vc or 'transient, could add a method to project-external-roots. That would be the user's job. I suppose Clojure packages declare somewhere which jars they use. They probably store this information in a file. Java used some ghastly .xml Ant file or Maven or whatever. A specialized project backend could read the file and use it in an implementation of project-external-roots. At this this is how I interpret project.el's CLOS-like protocol for defining new project backends. >> 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. Maybe. eglot-extend-to-xref works very well for non-jars, at least for C++ and clangd. Subsequent M-. work very well, too. The downside is that once a system file discovered by the LSP server, it is associated with a given server (_not project_) in Eglot. 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. > 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. That's a very nice point. I don't use Java fortunately, but when I did a long time ago, I think I remember Eclipse let me do this. > But as for xref-find-definitions, item 4 in your list should be enough > (with either of the alternatives as underlying implementation). Let's see what Danny says. Jo=C3=A3o