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: Sun, 26 Nov 2023 22:15:27 +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> <878r6mx1xc.fsf@betli.tmit.bme.hu> <90e4b9a7-3b51-587d-e317-b89e5d5464d9@gutov.dev> <87sf4scxax.fsf@betli.tmit.bme.hu> 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="10809"; 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 , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , John Yates , Ergus , Filipp Gunbin To: Felician Nemeth Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 26 21:16:45 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 1r7LYZ-0002b2-LT for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Nov 2023 21:16:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7LXd-0001aN-9J; Sun, 26 Nov 2023 15:15:45 -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 1r7LXZ-0001Zk-Lc for emacs-devel@gnu.org; Sun, 26 Nov 2023 15:15:42 -0500 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r7LXX-0003MM-5J for emacs-devel@gnu.org; Sun, 26 Nov 2023 15:15:41 -0500 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id CD0635C0088; Sun, 26 Nov 2023 15:15:33 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 26 Nov 2023 15:15:33 -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= 1701029733; x=1701116133; bh=HBNPP/f9bOu8lFNxB3wlfFw2uhzvXp3lAOA gKYGhGPU=; b=Fb7ZDOvlGohAZAFPOC3w9WvF0Agc6hQB0hc84k/X27KmLXfDSpK /A6RDXpxPIu8NenCNfiSXFJ3kQnQQa2NqN/WZu88zhVN6kbZReHJH13gcF0+ke4C b2V2QwwTkQCS2qE7bJDsTojjlLBioGch8asTrdH/CirStajP7lT4qHabNcY4tmyB ikAq5M+P6ij8FA/C51oxTaQuY8a82r6TxNfIHaju10M7B+m/x1qk8RLaO/ijl4YS 2mJCqtPvGQJ4SV5lb0TplN6nX0NL5MrdNAS5Gz20Pck9cGLZMfbPtQfQiyxXKSAb vRwqCuKCnDOp6vqTXcOprecBdsUYoYJIRcw== 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= 1701029733; x=1701116133; bh=HBNPP/f9bOu8lFNxB3wlfFw2uhzvXp3lAOA gKYGhGPU=; b=gx9qGMAIVrj4fGDxb/P/3cdKFRqt9dKWAma6cv/t+S/jJSAQeFr gLeZH/xKWe2HC9y9kcQKLjSKCMgcM8EjK6ECoS5tzDtRkdGLow/HosLmloLzE4WD zwDeEZs71+wZAJcBO3KxaJNyhx2JTt1CT14/MVDN+6uSWjOqlvCWiAhvrZFoCac3 PD58m/P4YyiOAJ8p5s/hSlDXB6ZYkBEWnUDseHQQFBoqNPnSugEDddnIqQyo4mwi 7hn+sx6WArIfMhVpRj9jVaFlJoRn51mpcvptjZdNSGZ5Ou7U/VHe89new8U23i0n UxKf2TQAuZdb5gfrvuhi//I7KOgep1NOW2Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehledgudefkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffg feejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 26 Nov 2023 15:15:30 -0500 (EST) Content-Language: en-US In-Reply-To: <87sf4scxax.fsf@betli.tmit.bme.hu> Received-SPF: pass client-ip=66.111.4.28; envelope-from=dmitry@gutov.dev; helo=out4-smtp.messagingengine.com X-Spam_score_int: -62 X-Spam_score: -6.3 X-Spam_bar: ------ X-Spam_report: (-6.3 / 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=-3.477, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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:313248 Archived-At: On 26/11/2023 18:08, Felician Nemeth wrote: > Dmitry Gutov writes: > >> Here's a refresher on the points of contention, in case you'll have >> something to add: >> >> 1. Whether Xref should have separate commands for >> declarations/implementations/type-definitions. With default global >> bindings (probably -- if we manage to get agreement on taking M-', for >> example). Or e.g. have a registry for kinds and letters, for quick >> selection between kinds (alternative for completing-read). Or just use >> completing-read and leave the definitions of all new commands >> (including the counterparts to >> declarations/implementations/type-definitions, of which then there >> will be multiple copies of) to the Xref backends. > > I have a completing-read-function that creates a single keystroke > selection, so the two alternatives are almost the same to me. I think the first question is what will be best for the default UI. And the follow-up will be, if needed, is whether anything else is needed to make it more easily customizable. A completing-read-function, or simply a UI which does what you describe, is not out of the question for this built-in command too. But if we tried to add it, then it's a question for how to choose the letters, and whether we expect them to be more-or-less stable over different languages and backends. If no, that's a bit of a bummer, given that one would often want to input their choice quickly, even without reading. If yes, then I suppose that means that the global set of "kinds" is actually stable, and it's either possible to create a mapping registry (characters to kinds), or choose a very stable dynamic algorithm (given that we know most of the inputs). > However, in the past it made sense to find the first xref backend that > knew the definition of an identifier. Now let's assume backend A > provides definitions with letter "d" and backend B provides > documentation locations also with letter "d". I think it useful to > allow the user to select between the two when xref-find-all-definitions > is invoked. And it is easier to create a flat list for completing-read > than for read-multiple-choice, for example: ("definition/A" > "documentation/B"). Eglot's integration shows that we don't in advance know whether a backend actually supports a specific kind. At least, we cannot know whether that kind is supported for a specific symbol at a given position (my tests with Eglot in the Emacs repo and clangd more than often ended up in "nothing found"). So to provide a list like ("definition/A" "documentation/B" ...) we'd have to first query all available backends about all kinds for the symbol at point. I think somebody said that this can be slow at least for some kind/backend/ls combinations. >> 2. Whether Eglot should, in time, deprecate its corresponding three >> commands if Xref adds its own versions. > > I think one of João's design goals of Eglot is to rely on existing Emacs > features as much as possible. That was my expectation indeed, but lately he said that since the commands are already in Eglot, they will remain there. Among other things, it will likely mean that they won't be getting key bindings (aside from those assigned by the users manually). >> 3. How the new command (currently named xref-find-all-definitions) >> should behave: should it always ask for the kind, or have a default >> one (determined how?), or fetch all kinds by default and show them >> together, like the latest version does. > > I don't have a strong opinion about this. In elisp-mode fetching all > kinds by default seems to be the most useful. Usually there are no more > than a handful of items and it is easy to see their kind. In Elisp, though, the whole addition doesn't make much sense. At least I don't see the benefit: xref-find-definition in Elisp already shows all kinds together, and it's rare than one needs to choose between them. And together with Mattias E.'s work for detecting the symbol-at-point's context ('elisp--xref-infer-namespace', etc) this works faster automatically 99% of the time. My testing with the Elisp backend is what prompted me to try to re-evaluate how this addition should work, anyway. >>> I think it is a minor inconvenience that it is not possible to use >>> directly the symbol-at-point as identifier while asking the user for the >>> kind. That is a prefix argument causes xref-find-all-definitions to ask >>> the user for both. >> >> I'm open to suggestions. Using 'C-u C-u' for one of the choices? >> Adding a separate command with different behavior (and different >> binding)? > > If I'm the only one who'd be happy to have this, then a separate command > without a keybinding would be fine. It could also be an automatically generated kind called "all" in the list to choose from.