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.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Sat, 11 Nov 2023 02:16:49 +0200 Message-ID: <7c188f56-9d05-1d60-e0d4-752c0763703a@gutov.dev> References: <71ea5e83-183f-2ae3-8146-6a31045a0309@yandex.ru> <834jqzafse.fsf@gnu.org> <83h6uv47e8.fsf@gnu.org> <4639d7ca-2109-864c-33c0-38e65f26f262@yandex.ru> <835ybb3txt.fsf@gnu.org> <83wn3q311i.fsf@gnu.org> <412afa2d-5dbc-52da-39c4-99be3873929c@yandex.ru> <83o7p20wdi.fsf@gnu.org> <72b09256-5a1b-8962-9e3c-7d2ffd0dc0d7@yandex.ru> <83ilf925n8.fsf@gnu.org> <95afa441-18ae-e62a-be16-be73a545bbba@yandex.ru> <54cb435f-4d51-4c0d-43d8-2991dd7ee6bd@gutov.dev> <2a059680-825e-1ee0-5e7a-1127c3faab4d@gutov.dev> 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="22975"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: Spencer Baugh , emacs-devel@gnu.org To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 11 01:17:57 2023 Return-path: Envelope-to: ged-emacs-devel@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 1r1bhE-0005jw-5N for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 01:17:57 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1bgG-0000f7-3i; Fri, 10 Nov 2023 19:16:56 -0500 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 1r1bgE-0000el-US for emacs-devel@gnu.org; Fri, 10 Nov 2023 19:16:55 -0500 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1bgC-0004dt-No for emacs-devel@gnu.org; Fri, 10 Nov 2023 19:16:54 -0500 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DD5E85C02C8; Fri, 10 Nov 2023 19:16:51 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 10 Nov 2023 19:16:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1699661811; x=1699748211; bh=sJ4Ejfx1fNVc4vfPwg3l5sfeBHG5qVSb3m8 tBcrERo8=; b=Xq91utICP+t9ksfhn+2Py7MeSBnZ6CE8TrCdPuOjhY4hgctIgLs dEwSZ8chFWpO7O0CLthRvwfSuukm57mRk8DfaX6U8sJCfezNYeFUvNgrDgSA1fO3 jMwOzrsQ/0K50bpjey6DIDvPv4TRZKibc0sKtdsjnqHmmMyLQmfSr88NnS0uhfC0 XFYBxmnCQlJoJYr8/iIhZQwWK1LoIyjsdJHhn772RfKvm/No4A4QJAWEUFmUZfon yql8FgPBLT3CD+GtEhFSldH8EJun41KNI5N+W1BQ0W3HGK1Bo4+iJBdvcB/ti9E5 2oKWG5/6HumHA6EKTrnNY5TRmYw14iVz6YQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699661811; x=1699748211; bh=sJ4Ejfx1fNVc4vfPwg3l5sfeBHG5qVSb3m8 tBcrERo8=; b=HT023Y+hTPrXsbK2fjhE88gibEdQ3A7QUZymF2p1xBRkza2NACR Mvb/FG8Krn563du0c0eJ/9Xf0QYKYIiIPFS/7eCmvLMdHATYCytSwVUfNbAxIDZv jHbjnavTxVx1IIWpty+5JTDNeEXBk74KcmtQBk0UEXq/nSyPBrChiN2hQ/30SoCE DJlKOxGY0uZbpcd9vRpIey8fHY+/vIUwOmRvS0KTUWpQcH3vabTo/7bZqcjBcsp4 CGyoFi3uKiEfolbl3MEgfodOLVsdJsyzLKUdQ9GpqxWe8GhCbHqAOrWTHy/6thrY sGr53GAD4Rq1KhO5bCs2e+IpdP99v+7vCOg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddvgedgudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepueffveeiffeugffgveejvdegteeuhfdugfehleelfeejtdelteethfdtieeg vddunecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 10 Nov 2023 19:16:50 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=66.111.4.26; envelope-from=dmitry@gutov.dev; helo=out2-smtp.messagingengine.com X-Spam_score_int: -60 X-Spam_score: -6.1 X-Spam_bar: ------ X-Spam_report: (-6.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.265, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312508 Archived-At: On 09/11/2023 03:06, João Távora wrote: > On Thu, Nov 9, 2023 at 12:27 AM Dmitry Gutov wrote: >> >> On 09/11/2023 02:08, Dmitry Gutov wrote: >>> Do you know which category does "eglot-find-typeDefinition" falls into, >>> and why? Aside from the fact that it, historically, uses a separate >>> endpoint. >> >> Hm, according to >> https://github.com/rust-lang/rust-analyzer/issues/2541#issuecomment-565166660, >> "find-typeDefinition" goes to the definition of the type of the current >> variable (at point). > > That's rust-analyzer interpretation. In practice, servers can do what they > want. This is the LSP description > > The go to type definition request is sent from the client to the server > to resolve the type definition location of a symbol at a given text > document position. > > For example, an Elisp language server could use that to go to the place > where the `typeDefinition` of a given symbol is set on that symbol. Perhaps. But that's still not the definition of the symbol. It would more-or-less align with rust-analyzer's interpretation, as I see it. >> That probably means it doesn't really fit with the rest of the commands >> we're discussing, e.g. because the identifier it works on is actually a >> type name > > Not in rust-analyzer, at least judging by what you described. Seems > like the identifier it works on is a variable name, which rust-analyzer > then associates with the type (being a strongly typed language it knows > that) and then you get to the place where that type is defined. > Super-reasonable, for rust. Okay. That's an interesting indirection, and indeed it might be difficult to make it work otherwise via LSP. >> (so the completion should be across types? ideally, at least, >> if LSP supported that). Anyway, it shouldn't be mixed into "find >> definition", at least if we go by rust-analyzer's meaning of it. > > Actually, no. Precisely in rust-analyzer's case it could be mixed. > I see somewhere a reference to a variable, I do that command you're thinking > of and get the definition of the variable and the definition of the type of the > variable, both useful things. It's less useful if one considers that in the resulting interface you never just jump to the definition of the said variable, even if it's found unambiguously. You would always have to choose between the variable and its type to jump to. In that context, an additional command which would collect "everything to show about a symbol", including type definition, makes sense. For the less frequent cases when you want a more through overview. It could default to that behavior (asking for individual kinds otherwise), or have some kind called 'all' which would do this. I'd probably choose the former. > But you're right that it won't make sense for every possible > conceivable language or server. But just don't worry. Leave that > concern to server developers and LSP users. You're not going to > magically fix LSP with the xref.el feature. The Emacs-LSP marriage > is never quite perfect, but it gets a lot of love. > > Exactly like any good marriage should :-) That's poetic. Still, this change needs to work well for both LSP (an important backend these days) and for others. If we find ways to make switching between backends more seamless, it's an improvement.