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 18:23:24 +0200 Message-ID: References: <87il697r5g.fsf@catern.com> <87r0kw8nxu.fsf@catern.com> <3fe5a8cd-b355-d7eb-10ad-8846aef3387b@gutov.dev> <878r6mx1xc.fsf@betli.tmit.bme.hu> <90e4b9a7-3b51-587d-e317-b89e5d5464d9@gutov.dev> <87sf4scxax.fsf@betli.tmit.bme.hu> <9ac758b8-5fb2-9b3d-7947-96777694e3e0@gutov.dev> <2fe6c4f0-dffc-ce00-758e-0c431a803d4d@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="25611"; 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: Felician Nemeth , Spencer Baugh , emacs-devel@gnu.org, Eshel Yaron , John Yates , Ergus , 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 17:24:11 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 1r7eP4-0006Mc-VY for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Nov 2023 17:24:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7eOT-000455-MS; Mon, 27 Nov 2023 11:23:33 -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 1r7eOS-00044t-NK for emacs-devel@gnu.org; Mon, 27 Nov 2023 11:23:32 -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 1r7eOQ-0004wE-Ll for emacs-devel@gnu.org; Mon, 27 Nov 2023 11:23:32 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F1F735C0291; Mon, 27 Nov 2023 11:23:28 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 27 Nov 2023 11:23:28 -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= 1701102208; x=1701188608; bh=XAX/LwQvOJnh4fJ45/U/SZ/Jfy+RLl2HIu6 c+ZFg36E=; b=mPq29USE+gXd6maLeslsHFkarpoELs1Hx8adTPcU7x71f9QUDLx 7xUtkFqzKgjeLNtg7HcA+tmU7Pi7OnMqoSZFo+x1QqZfGUavCsjbXR2TVvVXxNSw ky/zLyyaBoDmXIZslwtFWnxS/p+cf/yCAtt5NYHnhaIbh7EFQjYHvd5BWvuTDHUJ x+BnNTKQnY7o+1EGyOiiliNXsekRls3bN52EOfiQZP6kGo9tioHvmIu3aqHfv0TP SqdfWbLi4TIvvLwYzJXAS1hvTUETAfFyp9BQO5k8SBZ+pE9cHaKMOark/wc8YEQY Yid1CTR3XjwRZn9XTP92mf1CnEU77jM9Glg== 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= 1701102208; x=1701188608; bh=XAX/LwQvOJnh4fJ45/U/SZ/Jfy+RLl2HIu6 c+ZFg36E=; b=ff2DOPudVkUbOsQlbBa1lVZmXqkaXbXU2oNVH7YI6WTv3QyvNsq faOgIHZ+jeZJG9vNSQfr/FDOL9qqtZ2o4tP8dmAwsf4fdZIevJCPsrz3N7XuUOWp IW5ZtYvCZUqXoZgNqw+nxVR5IKcEx/FdxoBZoh4vKBt3uxcU5DkhqeGCDdU8T2Sq iPPLQpt5mTMWl5HsP4c79CcONb2DSllAaVF/3Xa/XpF+L26kZ+aDYU7UTcpam0xn A0SLS1s+9zbuOBxWS7KMSK4mP+rSj0Gg0YAVAm9r81GXo1BhhICAGFuhs6pGtvGC AcIBYStSVkNmNvExIWRvVvkrgMSlO8Uhjtw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeiuddgkeelucetufdoteggodetrfdotf 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 11:23:26 -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:313282 Archived-At: On 27/11/2023 18:04, João Távora wrote: > On Mon, Nov 27, 2023 at 3:45 PM Dmitry Gutov wrote: > >> That didn't answer the above question. To signal "what kind of >> cross-references it can find", it would define >> xref-backend-definition-kinds with corresponding return value. > > The answer was in the first two words. "Of course", and the reason > is in the words following that. > > So to be clear, yes, c++-ts-mode, if it ever gets such capabilities > should define c++-ts-find-declaration, c++-ts-find-partial-specializations > and so forth, but probably no c++-ts-find-implementation (fuzzy concept > in C++). It should (or rather, it may) bind them in a given xref-provided > prefix map and they should become active when c++-ts-mode is active. > > For "references" and "definitions" the existing xref commands will do, > but the phrases "references" and "definitions" should well be in the > "prompt for kind" list as options. We in the end we'll have dozens of similarly-named commands with the same implementation, right? Some of them in the core, others in third-party addons. > And no, it doesn't take much imagination to do this for CC-mode as > well, if the backend supports both C++ modes. > >>> The major modes could do that, for example. They could do it by >>> linking the backend-created "one key/command" keymap into a special >>> prefix created by xref.el, doing so by calling a load-time xref.el helper. >> >> Okay, so we would create and occupy a new common prefix. But without any >> commands in it? How do you suggest we advocate for that around here? > > What's the difference between no commands and useless commands that return > errors? Existing binding that one could [remap]. Or an opportinity for an Xref backend to extend itself into corresponding types. > But you could put the existing xref-find-definition and xref-find-references > commands in it. Even the "find-all" could be there. That... doesn't sound very convincing, TBH. > Also, as far as I can > see, you are already ogling the M-' binding in your branch anyway. M-' has an existing binding, and the contents of the branch could help make a case to change it. And then, if we don't add other new commands, why force people to use "M-' M-'" if they could just use the "M-'" for the only new command. >> And I didn't just invent the need for faster interaction by myself - >> just look at the first responses to the prototype. Okay, perhaps some >> power users in this thread don't mind adding personal tweaks to their >> config to speed things up. But that means the OOtB experience will be >> lacking. > > I'm not saying the bindings issue isn't important, I'm saying it's > (1) secondary to the communication mechanism and the functionality > which is already pretty useful in your original patch in this > 20-years+ Emacs user's experience (and I don't keybind things). > (2) not something we should rush to solve by copying an awkward > categorization that doesn't fit the needs of languages. > (3) solvable in all practical aspects by judicious coordination > with backends and major modes. True. Aside from the issues of 1) naming, 2) presence of "references" in the set, 3) interface to "fetch all" which we still haven't come to accord on. >>> It's much more pressing to decide if/why you want a command named >>> xref-find-all-definitions to return things that aren't "definitions" >>> by any measure or what is pressuring us to enshrine >>> "declaration/implementation/typeDefinition" in one of our >>> most generic libraries. >> >> It's a framework, not so much a library. Although it has the latter's >> capabilities too. As a framework, we should consider what the end user >> experience would look like. > > Sure, of course. And it already does that it excellently in so many > good ways (IMHO the decision to copy SLIME's UI was excellent). But > don't try to make it the uberframework for finding things to the point > of making Emacs-wide commands copied from LSP that don't fit a bunch > of the vast amount of Emacs use cases. It's too heavy handed, > a step too far, not elegant. We don't have to copy LSP, or follow any of its subsequent additions, or even copy the 3 "kinds" already mentioned. But any tentative plan for making user experience across backends faster and more unified would be good to have. Even if we don't act on it yet, code-wise.