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: Thu, 9 Nov 2023 02:26:16 +0200 Message-ID: <2a059680-825e-1ee0-5e7a-1127c3faab4d@gutov.dev> References: <861qm4tkih.fsf@stephe-leake.org> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9706"; 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 To: Spencer Baugh , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 09 01:27:16 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 1r0st9-0002GZ-DQ for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Nov 2023 01:27:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0ssN-0007sZ-Sv; Wed, 08 Nov 2023 19:26:27 -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 1r0ssK-0007sL-Ms for emacs-devel@gnu.org; Wed, 08 Nov 2023 19:26:24 -0500 Original-Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0ssI-0002Qr-Ks for emacs-devel@gnu.org; Wed, 08 Nov 2023 19:26:24 -0500 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 1291E320096D; Wed, 8 Nov 2023 19:26:19 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 08 Nov 2023 19:26:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=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= 1699489579; x=1699575979; bh=3dJ4hO+UFJTzpRI1946TcDDhO4BWp3gtzll /dipVScE=; b=V1oK0/m42pYYFw/kpLVE0Bmsvs22o5lSJbiOvBnnkUaznaWeEdA y1zZCML4YhrDYsm+1+Cznm16AEma0pHLo25f2qLv7zLFVfuMt9Cm4F9uDGIL++Oq K+7//QzH9zJxyFntIRaFJS8biNK0Ldgml4c7K72SJsvbQ7vOH60VebIZTGkbVxrc JqqBkgR3mOoeFdTIp+X0eMPGC+ryWdoYUN1MWoEc90I03rrDX/V7o40+ZGQGxgBS HanDz2ErIQa1CZbiC6w8dEKEsN+ha5X4z42brH7271uYF+xIUsqPSMfqxDQaUdds UaTDEF8b/QAb/mZGJbP8r/A2ImNmtb3HfRg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=1699489579; x= 1699575979; bh=3dJ4hO+UFJTzpRI1946TcDDhO4BWp3gtzll/dipVScE=; b=c i9CFxJyqX9oPoQ+miSL2InD+ZRcKLfEGrgUx6MDLLn5XvORZT+jPd9BC3uW8cj9f YpjzuwIIX5H1lcwLndc7KfzjfvE/A8Py7xuFnthCacvuRleoqA5Jus9sVgQwvXDM 1pbjsHaGw/ckMkfAo078Lrbk/UQHZfs3ga9ID2+2ci6F0x3fvoSrNVDmAGYLvdl+ 9x3K31YYzGMXsYpsri2CEP7Uh2dK7zriacFBW5Xd1j8TEjhW7mcb/Vts6NrgoiOK Jlsfwh0IRWy/0gk0k67LX93ylCSgzXQBFvCusTqK9qPGgEEmtzkOC1Df4DVWYnhQ GfzMGlSow2j0beCmW9QCQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddvtddgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffhvfhfjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefghfffgeektdelkeejleefvdeivedtgedtveelkeekkedvtddthfevvdeileet gfenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Nov 2023 19:26:18 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=64.147.123.21; envelope-from=dmitry@gutov.dev; helo=wout5-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.277, RCVD_IN_DNSWL_LOW=-0.7, 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:312372 Archived-At: 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 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 (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.