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 17:17:51 +0200 Message-ID: References: <953056ea-9cfb-34ad-6515-9036633dfdbb@yandex.ru> <2d964697-2b4e-64c7-2f16-aae87e57def4@yandex.ru> <87il697r5g.fsf@catern.com> <87r0kw8nxu.fsf@catern.com> <3fe5a8cd-b355-d7eb-10ad-8846aef3387b@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="29898"; 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 16:18:56 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 1r7dNv-0007Vf-Fp for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Nov 2023 16:18:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7dN4-00089b-0R; Mon, 27 Nov 2023 10:18:02 -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 1r7dN1-00089S-8E for emacs-devel@gnu.org; Mon, 27 Nov 2023 10:17:59 -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 1r7dMz-0000Ta-7W for emacs-devel@gnu.org; Mon, 27 Nov 2023 10:17:58 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id EAC045C0189; Mon, 27 Nov 2023 10:17:55 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 27 Nov 2023 10:17:55 -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= 1701098275; x=1701184675; bh=kol7B5GXFgm6WP9qTCie4pSxhodNTO/wc1U 6DW86Rk4=; b=c2lXVSD2bsHiD6EvojaqglwTY8O3kM66GI1Xdy1RTNIeyQQvYwc 94lkCYAZFOZoZwpy1ai4Aa8aCRBVGgB20gm+SAJscceH9mZIvdOfLSeBZRo6dbaP RL9945KzTQ0kbCttr1woYam0EPW+vuCXeKuVEhK3aFseTzmJV16H+8M3ZJbQ0Izo Qhog4F5YjlODpKFpsWrhrC1seKvuox0ssTAntQypnXHspIa33IMh01B35ogd6ZDv SZHHB72PE0MArEeZpFUWh/iZFgp3e9B7aOFnZBmZ3Hfw8yvevfIx8JX+ROtoIvV0 xZI7YbIRndq6Em4iFIVIYSgZh2ju4onHw9Q== 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= 1701098275; x=1701184675; bh=kol7B5GXFgm6WP9qTCie4pSxhodNTO/wc1U 6DW86Rk4=; b=L6cFDL021LKUTM8XR0pK8iIp09Mpzw6uYHSi4wRmgoE5aaX5/nT GtVtps67hWfA2nQhpYSpS5nfXyE0c3Hl5qXoaXCgXzffJh8H3cNOslGaZlh+QqVI X5e6l4zlgQeNXtssLPIIJWzYQosdJ5Ic1W/vVOLJ71lHmiEm4YYC0OALTw9z6xLf wWLoaW+me7SRgtaVhwdWJWIfSjuxEhKmGpP6e1vJa3t6Xf5qp6U4kkGi4ytg4V4B SuhuaSgGq0jrrQaUeB9ZlBgKHIYKZhul8uhP7Wvgczz3nBXPYfMrzd0beuSz4RJD nxyG6VqPfniIhl4AT/Sn4WP/E3ImPTG3ZuQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeiuddgjeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenuceurggutfgvphhuthdqffhomhgrihhnucdluddtje dmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeff mhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrf grthhtvghrnhepueefuddugeeuueejgefhudeggfeuheehjefghfefjedtleekgfdvteeu leejffdunecuffhomhgrihhnpegvlhdrrghtnecuuegrugftvghpuhhtffhomhgrihhnpe gvlhdrrghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Nov 2023 10:17:53 -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: -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_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:313273 Archived-At: On 26/11/2023 22:30, João Távora wrote: >>> Some major modes will support things which other major modes do not >>> support. Users will use the best one, whatever it is, and we'll change >>> the default to whatever it is, eventually. I don't see an issue. >> >> I don't see why we have to limit the users to specific major mode, when >> one might have functionality others don't have, and vice versa. > > It's unclear what you are understanding of Spencer's suggestion, which > is also mine. > > I hope it's clear that in mine and Spencer's view if there is > support for a given finding a given thing of kind foo for a given > language, then there is an easy command for doing so. And if there > isn't that foo, there isn't a command for doing so. This is the way > it should be. > > In my view, again, we should not limit ourselves to a triad > of kinds clumsily inherited from LSP. We should limit that LSP > concept to Eglot. It is not flexible enough, because it can't > be. But Xref is for much more than LSP. What it seems you are saying is that we never should try to extend the set of definition-finding commands above what's already in xref.el. Because it seems clear that we're unlikely to find a more widely-supported set of additional kinds that the aforementioned triad, in any medium-term future. >> Like now, for example, many will likely stay with CC Mode for a while >> because of it more lax behavior in macro-heavy codebases, where >> c-ts-mode chokes and shows syntax errors. > > Whatever you are suggesting, I don't understand. Whatever xref backend > is written for c++-mode with its special-purpose commands for finding > C++ things can be used for both c++-mode and c++-ts-mode. Just put that > code in a special file. What about default key bindings? >> Anyway, I've pushed an update to the same branch >> (feature/xref-find-extra). Again, it's something to try out, not a done >> deal: >> >> * The command is called xref-find-all-definitions, with appropriate >> behavior when invoked without prefix argument (appends the results from >> all kinds and shows them together, with duplicates removed). > > I think this is a mistake and a regression from xref-find-extra. > The command should be called xref-find-all, xref-find, or simply > xref, since definition is a category that doesn't span a lot of > useful cross-referenceable constructs in many languages. In C++, > for one, a declaration is absolutely _not_ a definition. It's a "definition" in at least one Xref-related sense: it should be dispatched through xref-show-definitions-function. Further, I'm not sure that when a user looks up all definition-related things for a symbol, they wouldn't want to see the "declaration". In fact, if we classify 'defgeneric' as declarations and 'defmethod' as implementations, I'm pretty sure I would want to see the former in the list. And you yourself mentioned that "type definitions" might be suitable for that list (which I found surprising at first). So it seems clear that there is no single red line. >> * The Eglot implementation doesn't include 'references' in the list of >> kinds anymore, just because those are not definitions. > > A mistake, but at least I can roll it back easily. > I would like the new interactive "find all" command (whatever you decide) > to show me "references" as one of the kinds of thing to search for. Then the list of results would drown in "references", wouldn't it? And its output would (or should) be the same as 'xref-find-references'. That would make it fairly pointless, I believe. > Why are you rolling back this useful stuff? Are you even testing? Because > the current branch doesn't even work in Eglot. Sorry, I didn't test the Eglot-specific commands. But their definitions should be 100% the same as the new Xref ones. >> * New commands for the 3 popular kinds, bound to "M-' e", "M-' i" and >> "M-'t". The command which shows all moved to "M-' M-'". > > A mistake, again. I wonder why you are doing these opinionated > changes to the branch you yourself proposed and which I put work > into. For experimentation. > If you are proposing this is brought to master for experimentation, > and if you are wary of this step, then may I suggest we push the older > more conservative version, perhaps with some naming changes? I'm not yet seeing a common basic version for which there would be agreement. You just called a renaming a mistake and disagreed with the principle of what "definition kinds" should be. > This new version isn't something we can roll back easily, while the > more conservative approach could eventually be enhanced with the three > "popular kinds" later on. I'm not proposing any merge to master yet. >> What does everyone think? > >> xref-find-all-definitions is an interactive native-compiled Lisp >> function in `xref.el'. > >> at point, prompt for the identifier. Interactively, show matches >> for all supported kinds. When invoked with prefix argument, >> prompt for KIND. > > I can't get this to work btw. If I add a prefx argument, it > prompts me for the identifier, which I don't want. What's what the docstring says, and it's what Felician brought up as a problem. Do you want two separate commands? And one of them would always prompt for the kind to use? > So will you please roll back some of your changes so we can > at least get something working again? Everything is "working" there, except for Eglot-specific commands, which are trivial to fix. I just did that, you can test.