From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#58790: Eglot URI parsing bug when using clojure-lsp server Date: Sat, 29 Oct 2022 17:54:23 +0300 Message-ID: <37716e41-5955-99f6-5204-e760a716fbf6@yandex.ru> References: <8cf8ba5d-c604-b2dc-274a-7597b19fb73f@dfreeman.email> <87ilk5xq01.fsf@gmail.com> <87r0yrwfn3.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31524"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cc: 58790@debbugs.gnu.org, Stefan Kangas , Danny Freeman 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 Sat Oct 29 16:55:26 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 1oonF8-00082V-1v for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Oct 2022 16:55:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oonEw-0001Sp-OK; Sat, 29 Oct 2022 10:55:14 -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 1oonEt-0001Ri-1h for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 10:55:11 -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 1oonEk-0002Cy-J7 for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 10:55:10 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oonEk-0003HI-8e for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 10:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Oct 2022 14:55: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.166705527312554 (code B ref 58790); Sat, 29 Oct 2022 14:55:02 +0000 Original-Received: (at 58790) by debbugs.gnu.org; 29 Oct 2022 14:54:33 +0000 Original-Received: from localhost ([127.0.0.1]:36337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oonEH-0003GO-4K for submit@debbugs.gnu.org; Sat, 29 Oct 2022 10:54:33 -0400 Original-Received: from mail-wr1-f43.google.com ([209.85.221.43]:33532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oonEF-0003GA-Df for 58790@debbugs.gnu.org; Sat, 29 Oct 2022 10:54:32 -0400 Original-Received: by mail-wr1-f43.google.com with SMTP id h9so10128354wrt.0 for <58790@debbugs.gnu.org>; Sat, 29 Oct 2022 07:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=+IkzGP/PDMIUP/e70aAvBQZ8Hpo7hGnab7V/V0bonq0=; b=EnOU+aUeTEpCSGGgUme9+aimn1pH4Li9Gx2Hw4J047NE2f7xLIB+S78PKl8WIhK1H6 1esFzLItI82QorS9O+u+2vfI8kZJWNuV/uc/x5rGtYV5hMXAW3m5xR1wzpxjDqPe9qm9 AEMhzU2Y82bdmTrj0Rd55WIM6f4vqKZQGLD+Op7IIaoOdFCrhb7q8xSjslJYLzRYDK3W EUHqm5xQigksp+4JDrWCAfdJH0a2A78PTMq4PtMP7NBCizojW/Tnct6+DajtYlPU3PPB UpEI0k+RlgdUj4nY5LyocmNH9Lp3ZykdNO+qOqE3bj4d8Lt5IRXXXPssdq0mIsOzi1zJ ydfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+IkzGP/PDMIUP/e70aAvBQZ8Hpo7hGnab7V/V0bonq0=; b=fZtadXJOqQCAPbvJVfhvwkNb71zNz2nhoGEX8leZike+MpKri2xY5K288kUWZzdzjd GjgagOpkVEYlQg7GmyPY37M0T/DBMxzpZ6VeK01/PizBjq8Q/cVRsyIVRJqzs6TqDUFT KH1QC7HMwUWkgWx0HcwprrVsu7SYSZy8lvxDm0IQkUq08tNvBan8Q6pw8A63zNhnSo0x Piq0SoqKls8vW/pKk5avVBTV01fs7FM9YbEFgXxcpkxvvNnzjJh8bdYl+8EDTg6EOlj0 Nycs+0/NfSSSutigreSAkdYRb8jahyahQSIi/8VcqkujQSfUD3P5WQvL9ig5ksfrr9Yn HRyA== X-Gm-Message-State: ACrzQf0mEuI/CAygvN++LQuy9LRHGV5jdISwj2oMc5It1OBzE1ZdHnII 5BfHfq96ckszeO7fnFXnw+k= X-Google-Smtp-Source: AMsMyM7jBDVFD6EmDfInAJyE/TAVJAdC10ogwFEayc1J2fx8M9fDTpF/okN5veGzHYNoBC0kPXIyhw== X-Received: by 2002:a5d:590d:0:b0:236:4ddd:1869 with SMTP id v13-20020a5d590d000000b002364ddd1869mr2423966wrd.709.1667055265210; Sat, 29 Oct 2022 07:54:25 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id bd26-20020a05600c1f1a00b003c6b70a4d69sm1833119wmb.42.2022.10.29.07.54.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Oct 2022 07:54:24 -0700 (PDT) Content-Language: en-US In-Reply-To: <87r0yrwfn3.fsf@gmail.com> 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:246536 Archived-At: On 29.10.2022 05:02, João Távora wrote: > 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. > > Eglot doesn't care if the project is of type 'vc, 'transient, > 'visual-studio-solution-file, 'joes-complicated-project, etc. > > 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. That was my impression, yes. > 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. Okay: some new project type. Or a new feature that parses build files. Or etc. All of that could be reasonable, but is yet for somebody to design and implement. IMHO a feature that takes up the goal of providing comprehensive IDE support could take up that responsibility too. But I'm fine either way. That would also depend on whether the LSP protocol is ever going to be extended toward providing build file information, running build tasks, etc. >>> 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. The dilemma of having external files associated with just the latest server seems unavoidable. Of course you could collect the full list of servers which the external file "belongs to", and then flat_map the requests through them all. But it's probably not what the user expects most of the time. >> 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. Maybe it's covered by existing LSP functionality, though.