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: Mon, 27 Nov 2023 20:12:47 +0200 Message-ID: <83136657-817c-6cd3-93e1-5f2af70667f8@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> 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="16319"; 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 Mon Nov 27 19:13:53 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 1r7g7D-0003vi-Vy for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Nov 2023 19:13:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7g6N-0008FW-J5; Mon, 27 Nov 2023 13:12:59 -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 1r7g6L-0008FM-QP for emacs-devel@gnu.org; Mon, 27 Nov 2023 13:12:58 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r7g6J-0000F7-LN for emacs-devel@gnu.org; Mon, 27 Nov 2023 13:12:57 -0500 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4908F5C039B; Mon, 27 Nov 2023 13:12:54 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 27 Nov 2023 13:12:54 -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= 1701108774; x=1701195174; bh=HlMyR5L0LUEouGpDP2lC7okU+6W71MtlRId ypelVUAI=; b=cWddR/LXg0dKPoCej+yAi4XZyIbhDpNclNMhh8CWNjYyHZ8panO TudLRNCt3V74FVbqeCiGWM08Y+pLIDrpIwXp2CZ/yssGGeqQ+He/GoLu0CvCsoCn zNWaU+NBwhPqg8npsyYZvZ5ohYb5nd3N5Oy7amXWPBiLPD9ayRJkCj+PxaVrJzph IVT1++nSJvS5V+/SNomfn7jyT0bdHIklpROzJNFMnt8YEoxXJ99fEGVZG8rHagxm 7Fu8oMQXM5nWIUGzBy+5Ms+TO+qY70PcxjiiQzqU2q6fy56PB3I4CAIOwH0V3sTP BCqeLmxM0p5MGWui6ZsCJKnc0MD6lMDs+7A== 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= 1701108774; x=1701195174; bh=HlMyR5L0LUEouGpDP2lC7okU+6W71MtlRId ypelVUAI=; b=sVYpzKqVa4jyOtYuHLKIjaoA2iZZTpUPwj7WNxgxm+usfmYqksY nztvy6rFLlHBXOfZQ9pEnxuedQZujiudlGGepDDCOofVsUlbk+1misHSwM3VcTQO o57faZw42mxEm9jOWCIsRYKtO+kOhms3t5fB0ajw/tezIOoqKSWHicWSmmPjHokI nQhza5G5CcqB0jJJUIgRwBJEiNtjQQKiHNri7vCNe8WEZ2569aNejKpbGGEGiA6T mGUVP9SJWRcUi9BspYEIwOIpTDWBQ/7NQpNQY1mM3w6D6sIcjMoAkVrhmb73XiSE 3y9IS7lnTfKIsw9/ySY+l6kqmZS3lWSlUhw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeiuddguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffg feejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Nov 2023 13:12:50 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=66.111.4.29; envelope-from=dmitry@gutov.dev; helo=out5-smtp.messagingengine.com X-Spam_score_int: -46 X-Spam_score: -4.7 X-Spam_bar: ---- X-Spam_report: (-4.7 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=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:313294 Archived-At: On 27/11/2023 19:46, João Távora wrote: >> It's about "set of things where I usually want to pick only one and jump >> to it" versus "set of things which I usually want to see the full list >> of, which stays around". >> >> You can say that "definition" is perhaps not an ideal term for the >> former. But the distinction is useful, and if you have better naming >> suggestions, go ahead. >> >> Until now the only built-in commands which went through that dispatcher >> were the variations of xref-find-definitions, so the name wasn't a problem. > > This whole thing started because you used that misnaming of > existing things as a justification for misnaming new things. And "implementations" are not definitions? Are "type definitions" not "definitions"? What goes for declarations in a lot of cases will also be "definitions of some sort". E.g. in Java a method declaration is its abstract definition in the interface or parent class. There are also abstract method definitions in C++ and so on. >>> No, not pointless at all. My main use case for this is to >>> first invoke the command on a given place of interest and _then_ >>> ask myself what I want to see of that symbol. "All references", >>> "definitions", "declarations"? >> >> The combined view, as implemented in the current >> xref-find-all-definitions by default, will then just show references. > > Not necessarily, it depends on the backend's. But yes, it might. How wouldn't it be? >> Why would you want to also be able to reach "references" through that >> interface anyway? > > Why not? To avoid the noise of that categorization. To get to some > reference type not explicitly covered in those other categories. To avoid the noise, you can just use an existing separate command. >> Like I said, they are not "extra" because they will on most cases >> include the kinds already shown by xref-find-definitions. I'm open to >> other names, but please keep the intended semantics in mind (see above). > > How bout "cross-reference", or simply xref? There's a reason why your xref.el > which you maintain inherited that name from SLIME by whoever ported the UI > (Helmut it was, IIRC);-) There's a lot of wisdom in that name. That's the general term for all thingies Xref shows. The "xrefs" in the name "xref-show-xrefs-function" stands for pretty much that. 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).