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: Wed, 8 Nov 2023 01:30:09 +0200 Message-ID: <54cb435f-4d51-4c0d-43d8-2991dd7ee6bd@gutov.dev> References: <83pm9sfxfa.fsf@gnu.org> <861qm4tkih.fsf@stephe-leake.org> <71ea5e83-183f-2ae3-8146-6a31045a0309@yandex.ru> <834jqzafse.fsf@gnu.org> <83h6uv47e8.fsf@gnu.org> <4639d7ca-2109-864c-33c0-38e65f26f262@yandex.ru> <835ybb3txt.fsf@gnu.org> <83wn3q311i.fsf@gnu.org> <412afa2d-5dbc-52da-39c4-99be3873929c@yandex.ru> <83o7p20wdi.fsf@gnu.org> <72b09256-5a1b-8962-9e3c-7d2ffd0dc0d7@yandex.ru> <83ilf925n8.fsf@gnu.org> <95afa441-18ae-e62a-be16-be73a545bbba@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34284"; 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 To: Spencer Baugh , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 08 00:31:25 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 1r0VXX-0008mj-An for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Nov 2023 00:31:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0VWn-00063m-1I; Tue, 07 Nov 2023 18:30:37 -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 1r0VWi-00063T-Vx for emacs-devel@gnu.org; Tue, 07 Nov 2023 18:30:33 -0500 Original-Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0VWT-00017U-8b for emacs-devel@gnu.org; Tue, 07 Nov 2023 18:30:32 -0500 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 2BAC23200940; Tue, 7 Nov 2023 18:30:13 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 07 Nov 2023 18:30:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=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=fm2; t= 1699399812; x=1699486212; bh=TvUnka9UJwzff2tuHJ1hYorT4IpM/NdzJ6P OQJD7QQE=; b=Pf+HLTl+z0V9bVTozGLKIBA0QYm8hfOruBfm7RjPVvbVALgFuEg 4ovokNKIT2x9OQ26S3Oj/B7T2DQ6kBZcTDc6Cdss2PEUdX4ZbxbBCDIJwfmjPukA aW8fW91loGDUz75exveoFecuEbSaszRhuVTfwkqtHrH+Arh/IHBaSSBhi5OpNbdx +y0WlZ2Q45+eqYHuouIPTQ5hrHS3IJwJLlv+bXsdQSUM9fBwnboK2hOCA4t+f/G1 CrRLAzXyEuIk/UESmZiaJWWx7CXyzMu2efnD3LtnopZyt6DqcRintZxLg1WVGGsQ sMcyAlQsfTuHbOyJ0rXc/HkNQhMDNqgBGgQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; t=1699399812; x= 1699486212; bh=TvUnka9UJwzff2tuHJ1hYorT4IpM/NdzJ6POQJD7QQE=; b=S VU8ZiBsEeH5nfEkUdId2G1euqe7tHm+Tej6tGJxY4extGMl0lf3Sr7MsuUoglHl7 WwSRXGSR6aMIj1G8Qfo/X3+Ft95f3Df70rcLzwfOlUGSgcpzqQSCI4YP2gUurio+ QOAcvkYcIxYugUQVjWVXFZz+WMHr5jB5/xGzmobCOOrnsx/cdCO8XxhoSidrJR5M wS7n0k92fP287TeFd//7sVrAzhvH5YevWMCBd3l23B0BwZRlUA8FNuyMnB6jEuz3 8pSqn3z59V/Jac/aSjurwFGpxjyBBgMWSQ5IBEGfaWQ1ohRnNKnP8elJSexnimtG 8l/vLObmq57ZnCpHBkKdQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddukedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeghedthedujeeiteeutddtjeekheejteeukeehffdutdejuedvfeevueeviedu udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Nov 2023 18:30:11 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=64.147.123.20; envelope-from=dmitry@gutov.dev; helo=wout4-smtp.messagingengine.com X-Spam_score_int: -44 X-Spam_score: -4.5 X-Spam_bar: ---- X-Spam_report: (-4.5 / 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=-2.344, 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:312327 Archived-At: On 07/11/2023 18:51, Spencer Baugh wrote: >> Perhaps it /should/ (xref-find-definitions to include both >> implementation and interface). And include the typeDefinition entries >> for langs that have those. Etc. >> >> Would the UI be worse? Let's try to find out. >> >> Attached is the patch along the lines that we discussed: a new command >> xref-find-extra currently bound to M-' just for the sake of this >> experiment (eliminating the need to set up define-key to try out the >> "fast" workflow). It uses the symbol at point or asks for it, then >> polls the backend for available kinds, does completing-read and asks >> the backend for definitions of that kind. And shows the list or jumps >> to the unique one. >> >> To have something to test, I implemented this for Elisp. However, all >> known kinds are already printed by the regular xref-find-definitions >> output in that backend. So the result turned out interesting, but a >> little impractical: with Elisp, we already make the choice between the >> kinds in the Xref output buffer, when that buffer is shown at all (as >> Eli pointed out, actually). So... we could proceed in that direction >> and recommend that all kinds of definitions would be added there. > > This (and Joao's patch adding support for eglot) is very interesting, > thank you for implementing it! > > We also discussed a UI which shows all kinds of definitions in a single > buffer. Maybe the prompt for KIND should default to "all" which shows > all kinds of definitions? The natural question is whether 'xref-find-definitions' would be that UI, and if not, why not. Also, if "references" are included in the list of kinds (as the current patch for Eglot does, I think), then "show all kinds" is not likely to be very useful -- all will drown in "references". > I notice the API doesn't support "fetch all kinds of definitions"; > extra-defs requires specifying a specific kind. Perhaps just specifying > a nil KIND should request all kinds, and extra-defs should tag each > returned object with the kind? We could also just make a separate call > to extra-defs for each kind returned by extra-kinds, but that would be > allow less space for the backend to batch its operations. That's a question for later. >> Or perhaps the main value would be in actually having separate >> commands which could be bound to a submap with faster key sequences >> and/or to the context menu (with context-menu-mode on). Then our >> solution should be more in line with either defining a number of >> additional named commands (for mode universal kinds) and/or making it >> easier to define new such commands for users/3rd-party packages/etc. > > That's an interesting idea. So maybe M-' (or whatever) could be a new > prefix for a prefix-map which contains both universal and mode-specific > kinds of lookups. > > So maybe something which looks kinda like (not suggesting final > bindings, just trying to feel out what it would be like): > > generic eglot-find-implementation: M-' i > generic eglot-find-declaration: M-' d > generic eglot-find-typeDefinition: M-' t Then we will more-or-less nail down the whole set of "available Xref kinds" in the core by having these commands defined. That's not very flexible, but if the set doesn't actually change too much, and doesn't vary between languages a lot, it could work. Would lead to a more straightforward design, too. > xref-extra-kind, prompting for kind: M-' M-' Would we need this command, if we had separate commands for each kind already? > xref-extra-kind, showing all: M-' a > > And if there was something mode-specific, like the Java overriding > method thing, it could be e.g. M-' o Most of them are mode-specific already. Some languages don't have separate "declarations", some don't know what "type definitions" are, and some, indeed, don't have method overrides. > I like this sort of design a lot actually: > - it's faster to type than having to complete the kind name (IMO, having > to complete the kind name makes the current patch quite clumsy) > - it allows a common set of keys between all modes > - it's extensible by individual modes without too much trouble > - it works naturally with context-menu-mode and other menus Indeed. > (although I suppose we could automatically populate the context-menu > with the output from xref-backend-extra-kinds) Probably. > - users could still use completing-read to type the kind > > Plus, if we do use M-' or any other short binding for this, we should > almost certainly make it the start of a new prefix-map rather than bind > M-' directly to the new command; doing otherwise would be wasteful of > valuable keybinding space. If we're going to have separate commands for kinds, that is indeed a good idea.