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:04:02 +0200 Message-ID: <869c25b8-4c99-fb35-cd8c-b1a8a6256e04@gutov.dev> References: <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="994"; 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 17:05:08 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 1r7e6b-000ARq-Dg for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Nov 2023 17:05:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7e5k-0002A1-J8; Mon, 27 Nov 2023 11:04:12 -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 1r7e5i-00028i-9E for emacs-devel@gnu.org; Mon, 27 Nov 2023 11:04:10 -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 1r7e5g-0001DU-73 for emacs-devel@gnu.org; Mon, 27 Nov 2023 11:04:10 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3A3D95C0296; Mon, 27 Nov 2023 11:04:07 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 27 Nov 2023 11:04:07 -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= 1701101047; x=1701187447; bh=LmKAKi68hHuvzsC7lX8epRfF0g0Xh4nbag4 jxxXKdmU=; b=A/ogEe+HBtQbkPWD48UuYTtD0UezRdaD21eL4kCrkHh5vUn0B59 6Jsurr5pEmD3AzuuoISF8gPeVm/wdPt83Uxt7qz6gZwkb8ZEh36begEc8Nefk0HG fSvqDRUOJlzcSS2Q978OwvFpysQqbyx0D5EDk5z6xWRjKl6k25Hp+2G+U3CA2Yb/ 95eweEMAWT1mR84OmtjM3PLFMMSi4/Rr8nx6bZfua+LODVG4SmRGccxzfBPxEHsC GvtSspmG5ZhHohCnBbahAZxHD/chCrMIGaqIrNRfCHj5FVWZTlCNGHW79Mj7ZTdw l1JyIQPKj4CczatcMT0JNYh4CvuoYFGSnQQ== 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= 1701101047; x=1701187447; bh=LmKAKi68hHuvzsC7lX8epRfF0g0Xh4nbag4 jxxXKdmU=; b=kiOtGgL44joIfCcWbYiCnF4JtCD91sqngvZnOXdOxFiEVLH+fTE U662+yjjfiBH3xamjcbuOA66637Lsw4i/yikeMrI5dkDlH79+VNfr8jtzutuBTIE QRBCVhH/oeDvLwf1FOzTWAIgaJiiB6DHiBsakSblRaIFI8s9zu0UUPeF+Y3kwNIg p2ayuC3GGX+QFxgx652ktQIEwOJO5301nx/bMEf5AU6s5rGrZSn+/D/XHvLat9U6 QOVhpdkHQNKGWL9reJ9YiuRPQ0P20dAbEKKz2CjgMCq0A+WRsWTpaE5I69ggPN2u hTTr4H2t4nC8b05Ctvcdp8rfqoYuXfLewWA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeiuddgkeehucetufdoteggodetrfdotf 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 11:04:03 -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:313279 Archived-At: On 27/11/2023 17:45, João Távora wrote: > On Mon, Nov 27, 2023 at 3:17 PM Dmitry Gutov wrote: > >>> 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. > > Not necessarily. I'm saying we shouldn't make that a priority > or the rest of this useful feature contingent on that. If we > someday come to the blissful epiphany that every language ever to > be and to have been has the fundamental concept of a watermelon in it, > then we can think about xref-find-watermelon. In 20-30 years or so? >> 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. > > They're not particularly well supported, they won't age well. LSP > uses that trio for two reasons: it doesn't have major modes or a > programming language, and it's driven in part by commercial vendors of > specific large language implementations. But Editors like VSCode still > have "plugins" akin to our major modes. I don't know about aging well: most of the aforementioned ones have had meaning for the whole 15 years of my career (that's not too long, but still), and typeDefinitions is apparently something more helpful in newer popular languages which rely on type inference (so there's rarely a type annotation nearby to 'M-.' on). > I wouldn't be surprised if these plugins don't have total freedom over > what part of LSP they expose to the user. > > Opening VSCode on a C++ file for example, I see "find definitions" and > "find references" have dedicated bindings, but "declaration" and > "typeDefinition" do NOT. And "implementation" isn't even there as it > doesn't make much sense in C++. Ultimately, we could also show-hide definitions depending on which kinds the current backend(s) expose. I.e. a set of commands might be dynamically generated via dispatch (like project-switch-project does), or they indeed can be traditional commands. The latter has advantages: the users can examine and rebind them using the traditional methods. Indeed, some commands will be "unsupported" in some languages. I don't see much issue with it: if the language mode (major or minor) has a better command to use instead, they can [remap ...] it. And they will have a common prefix to add their own additional commands too. >>> 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. > > So it's a "definition" because the xref.el author called an > implementation detail a "definition"? What does the user possibly > care about that? Why don't you read up on the difference between xref-show-definitions-function and xref-show-xrefs-function. Those are not implementation details but something that affects user experience. And users can customize one or the other, which correspondingly affects dispatches which go through one or the other. >> 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. > > Of course, if the world is painted in the three LSP primary colors, > every other color will have to be truncated to that. But it doesn't > mean the world gets any prettier. Would it be better if the user has to type 'dec' in C mode but 'defg' in emacs-lisp-mode to get to a semantically similar set of results? >> 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. > > Precisely. So don't go making those lines. > >> o 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? > > But if I want to see references to the given symbol at point, that's what > I want! I press M-? xref-find-references all the time in Eglot. And that's great -- please continue to press M-? for that purpose. But if 'references' joins the "definition kinds", then the command to "find all definition kinds" will become pointless. And we already have command to "find all references". >> For experimentation. > > Then perhaps we could cut another less contentious branch off > 279203199a2d10677e42747476b39394a4184a78 > > Over that branch we can rename Eglot kinds to strings and "extra" > to "all". I'm sure that's less contentious, a good candidate > for master and not incompatible with evolving into whatever > results of your experimentation. See above. >>> 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. > > Well I am, but not of that code, at least not yet of that code. > Merge to master something useful that doesn't compromise us. We're yet finding that. >>>> 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? > > No, it's not. It starts prompting me for identifiers which for LSP > is useless. Eglot has no way to know which kinds of reference it has > for arbitrary identifiers not at point. I said that it matches the docstring, not that it's ideal for Eglot. > The only useful way for this to work in Eglot would be to prompt > for KIND and _then_ show the results, which may be empty. > > Anything else doesn't make sense for Eglot, for LSP-specific > reasons beyond my control which I've already explained. What about showing the combined set?