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 19:22:45 +0200 Message-ID: <680b567e-4a2e-d2d5-a2f4-423584a60a53@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> 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="28410"; 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 18:24:01 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 1r7fKy-000760-5P for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Nov 2023 18:24:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7fK7-0008Py-35; Mon, 27 Nov 2023 12:23:07 -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 1r7fK0-0008PY-Ad for emacs-devel@gnu.org; Mon, 27 Nov 2023 12:23:00 -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 1r7fJr-0007L8-9Q for emacs-devel@gnu.org; Mon, 27 Nov 2023 12:23:00 -0500 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9B6065C02F5; Mon, 27 Nov 2023 12:22:49 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 27 Nov 2023 12:22:49 -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= 1701105769; x=1701192169; bh=J6+LdXI29It0tck3PHs4beEdONvjYhHqlKU 9Z9B6LEU=; b=o/Oaz/g/duQri2VSyEhvF5RiCLmGDZAZMPIjvrMnSi7pK/rDe2j LKlq5aBHvNrPg+s05Qs2D3R1ODGrUCIvfeH9T0gpe53MXxDea+wWRfoigg/YdQeq 3ErV7ljY+7t87vvqAv+JLydRAX2fekZbQ1Bqqkxcm0BNaJ7DaZ/Z47v5YGrTGFXT AzYv9/nq6kaI9vTukspOHYhVkipxSRG+k0+GHklxXmuJWPnY4E945iIXkWiy5Gfu vuIdGAnXCdemqgVZBeq1y5T7NJJkZKebQ3YVsNwCj4h25DlkHkDpG/7oMqqhq9cm dP/pUfRJ6wQCuq/UTo8O8qIAmWjqetE5LyA== 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= 1701105769; x=1701192169; bh=J6+LdXI29It0tck3PHs4beEdONvjYhHqlKU 9Z9B6LEU=; b=jKdZ3qtbcyQuu3A9Bazu+HDfUDbZEtUE9ZYug+L7NIEAHgvRECR mzwmLXx5M5jFODXcrU6CYzyg2eaMRFJuozqqtaD7AFQzBqcnB8DmJ7ob9h/9P8gX s4kR2gA6aYuop3jCQfqMW1rCixgBLkyPmBi6XMG3HwSibi3AHp2dTiwzmrXQj5WY tyf9HO+xHyY583U2GmsSY23Jjq90wx2NxQ7inJGLTBiZKRcoMAV5bGULBzkkViYv jMGUWrFbOU1zjhDo5QXir64U3n5F29GWL4fOz6tq9clazLXxfT3CdDmkBwMuQwSH 8CUS6IjLy9D4SuHcNjqHwCLGCWyzFA1+45w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeiuddguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpedvteffkedtffdtleeltdegtdduudffhfdvieelgfefudejhfehieeuuefg heegueenucffohhmrghinhepghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Nov 2023 12:22:46 -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: -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:313290 Archived-At: On 27/11/2023 18:27, João Távora wrote: > On Mon, Nov 27, 2023 at 4:04 PM Dmitry Gutov wrote: > >> 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. > > First, who does that? I thought you were concerned about > the OOtB experience for non-powerusers. It doesn't take a power user to use the Customize interface to set xref-show-definitions-function to xref-show-definitions-completing-read. Who uses that? I do, for example. And the people who asked for it (see https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00824.html). There are also third-party packages which provide alternative UIs through these options (e.g. ivy-xref and helm-xref). > Secondly, if something called > "definitions" is used for things that are patently not "definitions" > that thing is incorrectly named, period. It's not because that editor > thing was misnamed by its creator that magically my C++ declaration is > now a definition, too. 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. >>>> 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". > > 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. Why would you want to also be able to reach "references" through that interface anyway? >>>> 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. > > So, awright. Do you really really want to rename "extra" to > "definitions"?? is that the blocker? Makes 0 sense, but if > there's no talking you out of it then I guess users like me > can swallow the awkwardness and translate "definition" to > "thing" in their minds. And we have strategies for renaming > things anyway. 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). >>> 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 exactly is compromised by that patch? And do you not agree > it is minimally useful? You wrote the thing! Noone forced you to. I voiced my doubts in the very first message that patch was attached to. And that it's experimental. It's also like 20 lines total. Let's keep a perspective.