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: Tue, 28 Nov 2023 02:30:09 +0200 Message-ID: <855e37c2-9a82-d4b8-1f75-07ee59a7c1d0@gutov.dev> References: <87il697r5g.fsf@catern.com> <87r0kw8nxu.fsf@catern.com> <3fe5a8cd-b355-d7eb-10ad-8846aef3387b@gutov.dev> <869c25b8-4c99-fb35-cd8c-b1a8a6256e04@gutov.dev> <680b567e-4a2e-d2d5-a2f4-423584a60a53@gutov.dev> <83136657-817c-6cd3-93e1-5f2af70667f8@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="35823"; 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, Eshel Yaron , John Yates , Ergus , =?UTF-8?B?RmVsaWNpw6FuIE7DqW1ldGg=?= , Filipp Gunbin To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 28 01:31:27 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 1r7m0c-00097M-23 for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Nov 2023 01:31:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7lzi-0005Z6-98; Mon, 27 Nov 2023 19:30:30 -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 1r7lzh-0005Ys-0u for emacs-devel@gnu.org; Mon, 27 Nov 2023 19:30:29 -0500 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r7lzT-0002Y5-A9 for emacs-devel@gnu.org; Mon, 27 Nov 2023 19:30:28 -0500 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 781C65C0270; Mon, 27 Nov 2023 19:30:14 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 27 Nov 2023 19:30:14 -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=fm3; t= 1701131414; x=1701217814; bh=Jon3LgbT+QvzRodVDbkH4QhDIZQK2JtXvNF q8EID4Lc=; b=F6+wqqTNq1aoymfp67MIM16s+B7hVWwaAFHEH5k1Ygfk40UGJNo +tDoZPnQYuSACMcKYORk1xR84CKw5AC2B0SE9KA4G1mHnv3mbPc71sHDjohpGAd2 50nFxjFIzGx7N2Exhj13ZWE/bbwQhKHzjzR6cgQtKds94p2kw6TAN2hhMxKsAr9Q 9F8T8xdnwFe6i/KpktRF9/Asn6X6DJZhbGp71u4L3rlg+BjBUKrFZRwd+rg/EjLM UpjFNHfZgSbMUXkCxAeU3PeI4YSHg8mYlqwXK9cmfR8QRSVj1TitYfkYNlMDHltq DPY7Ez36LT0mje5+5pQO9OlXCMb0uez++2w== 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=fm1; t= 1701131414; x=1701217814; bh=Jon3LgbT+QvzRodVDbkH4QhDIZQK2JtXvNF q8EID4Lc=; b=PFdl9RemWqYl9fVDstZvi3VBj6ecp48v+sK49R9AZDQUlhsHZ74 kwujHtJs17fTxIDFlaCTIXNupSq0H93ZB3DPdntwZz1BRmdQUUzKG4He03wBHjWw 2A1aivYucq4ontJ9U2Ersmbgh/Y3x2mYAL5E7vPceiyqg77LMq3BtKAlRGaCKRqj wC6Y4re4U1fsvtr3/pLWm4DKAZbY/zOYCqP51FdNcvSGPhJuBT929UIuawJsjMtS N9iXK4Uu7sDY/MECD4l4xJWQTG9fVWaCecSGB0p8/LBlGYRW/SKeDrDaETPm2KUO 4fqAGOR/ckONvIWt0UpqkfRmolODIcTBmYg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeivddgvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Nov 2023 19:30:10 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=66.111.4.25; envelope-from=dmitry@gutov.dev; helo=out1-smtp.messagingengine.com X-Spam_score_int: -39 X-Spam_score: -4.0 X-Spam_bar: ---- X-Spam_report: (-4.0 / 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=-1.857, 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:313304 Archived-At: On 28/11/2023 01:25, João Távora wrote: > On Mon, Nov 27, 2023 at 6:12 PM Dmitry Gutov wrote: > >> There are also abstract method definitions in C++ and so on. > > No, there aren't. You probably mean "(pure) virtual member function". > And yes, I can assure you that's the jargon that professional and aspiring > C++ developers prefer when communicating with colleagues and compilers, > certainly not wishy-washy Javaisms. My deepest apologies. >> What goes for declarations in a lot of cases will also be "definitions > of some sort". > > But if you squint hard enough, everything's "definition". In fact, > definition definition definition. Definition? Definition! Unless it's a reference (call site of a function or a place where a variable's value is looked up; or referred to in a doc). So yes, these are basically two categories of xrefs we distinguish: definitions (only one or a few of them for a given name; usually want to jump to one) and references (usually many of them for a given name; and we would often want to see the full list, to read or search/replace against it). So in that terminology, both declarations and implementations are "kinds of definitions". If there are suggestion for replacement of that term, I'm happy to discuss. >> If you don't like "definitions" in "xref-show-definitions-function", >> then it would need to be a term that describes "special kind of >> cross-references". Probably referring to the kinds of locations those >> cross-references point to (which determines the optimal UI). > > I'm fine with that name myself, it's specifically for xref > -find-definitions, right? And for declarations/implementations, and so on. Again, xref-find-all-definitions might be renamed, but what it does by default is find all definition-looking sites for the entity at point. Which seems useful enough to me. And which also implies that "references" of any sort should not be in that list. Just to reiterate: xref-find-all-definitions calls xref--show-defs which displays the results using xref-show-definitions-function. > I just find it nonsensical to use that > to justify the "definitions" in your proposed xref-find-all-definitions > which potentially serves to find C declarations, C++ deduction > guides, Elisp feature-providing forms, CL macroexpansion loci, > etc, etc. I've given plenty of alternatives. The only alternative I remember you suggesting is using "xrefs", which was missing the point.