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, 12 Nov 2023 03:50:36 +0200 Message-ID: References: <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> <54cb435f-4d51-4c0d-43d8-2991dd7ee6bd@gutov.dev> <4b0b05a2-8c83-7026-4310-327d595dfd8a@gutov.dev> <87cywg8mx0.fsf@catern.com> 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="17240"; 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 Sun Nov 12 02:51:44 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 1r1zdW-0004FR-Fl for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Nov 2023 02:51:43 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1zcb-0007Ob-8l; Sat, 11 Nov 2023 20:50: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 1r1zcZ-0007OQ-FO for emacs-devel@gnu.org; Sat, 11 Nov 2023 20:50:43 -0500 Original-Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1zcX-00017x-9u for emacs-devel@gnu.org; Sat, 11 Nov 2023 20:50:43 -0500 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 7829F32003C0; Sat, 11 Nov 2023 20:50:39 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sat, 11 Nov 2023 20:50:39 -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= 1699753838; x=1699840238; bh=pMIKHbGD5HXisIFeMFx3LJorRyW0T9e8rfx M3lynKrU=; b=TlOC7JUfdww8B7fGtiuqwmsgEsfT4I2KCpUTzCUt9T89cxeg4/e g5rTTkVlRC8Z03iQ7k6U60MEqDLWFdPFua0y/upcCZSr5l46xYaUaju9LStyx9EN 9ZLZreoufrOLKVvvIQQV7VSPZkkiCtg6CbxjV8kBWu4rECEEgHPb5abx7m27NlSG Z/l0XtiFynrr3PC54byxaVLXzA8z++SzR/Cvk7cyy0jhfs/aOvqeHjji9rymKFqL OzRgqsmYS6IBud9R2CpZdxECz2W8NYq2uwsRsfS7wVR3iktOO3XgxIEVronGMPmX +dj29XQDn05AL6B2dQpORmSPdc9heabhpOw== 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=1699753838; x= 1699840238; bh=pMIKHbGD5HXisIFeMFx3LJorRyW0T9e8rfxM3lynKrU=; b=g FKlVLsYw08ihDjLxMCiU6ZzwbcajKnBC3f4jYdpkS1/2m7gKD5bPvyXB257NPA1l swB5y2mI/Ko3wfc9ccsA9NCxl7n3t3bkITPHwrTx79TyJfDSUYbGbJVG7xLN4zWB 5MzWuZwdTgW91yb3DmWAwcBYVdBWLNm2+VEPfDVGxA6s0VMvS7txdSnKZFeGp6Fr urZf+YPLU1IQGpYjZq0OlWksDorBSSs/7oXgGt0WNdY4exUXX/FtfOIXesPk2sic iUZXm6SRE0Jyv5jGQVOEOeydEM61asxlANaphQ2z2iTaincWt1iHpY4DOK3DvtrC O7CM2j9wvW98F2WrA8Iqw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddviedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeghedthedujeeiteeutddtjeekheejteeukeehffdutdejuedvfeevueeviedu udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 11 Nov 2023 20:50:37 -0500 (EST) Content-Language: en-US In-Reply-To: <87cywg8mx0.fsf@catern.com> Received-SPF: pass client-ip=64.147.123.24; envelope-from=dmitry@gutov.dev; helo=wout1-smtp.messagingengine.com X-Spam_score_int: -69 X-Spam_score: -7.0 X-Spam_bar: ------- X-Spam_report: (-7.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=-4.148, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=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:312622 Archived-At: On 11/11/2023 15:00, Spencer Baugh wrote: >>>> We could indeed, if we decide what to call it. "extras" seems out >>>> (since it would include both definitions and additional reference >>>> kinds). Just "xref-find-by-kind"? Then it's less obvious to have the >>>> default behavior showing all. >>> Actually, maybe this should be a backend-specific thing. The >>> backend >>> could specify a default along with its list of kinds. And if we request >>> that default kind (which might be 'all), then the backend will decide >>> what kinds to send us. >> >> If the backend specifies the default behavior of xref-find-by-kind, >> then it's what, another generic method to override? > > The default could just be the first in the list of kinds returned by the > backend. So... one backend would show implementations, another "all kinds", and the third one "definitions"? That seems odd. Moreover, if I don't have any idea what the average backend would do, it's harder to write the docstring, or describe the command in the manual (check out the current manual entries related to Xref; that wasn't me who wrote them). I was also thinking to suggest the command name xref-find-all-definitions, but that one clearly implies what its behavior will be when called without prefix. >>> Actually, it occurs to me that if we had an xref-find-implementations >>> command from the start, with a convenient binding, maybe >>> xref-find-definitions would just only show the cl-defgeneric, and jump >>> to it right away. And only if you hit xref-find-implementations would >>> you jump to the cl-defmethods. We can't make that change now, but I >>> don't think it would be worse! And if a backend wants a design like >>> that, I think the backend should be able to have it. >> >> Not sure I would like the result that you are describing, but indeed, >> if a backend wants to do it like this, nothing will be stopping it. >> >> Are LSP servers behaving like this? E.g. jdt-ls jumping to the method >> definition in an interface, even when the owner type is a statically >> known class? > > I don't know about jdt-ls or indeed about LSP servers, but the xref > backend for Merlin (used for OCaml) by default has xref-find-definitions > jump to the signature of a function, not its implementation. Unfortunately, I don't have an intuition for how this works for OCaml in other editors, or worked in the past, to compare. > There's a user customization to toggle whether it jumps to the signature > or the implementation. And if the customization is in "implementation" > mode, there's no way (through xref) to jump to the signature, and vice > versa. Adding a way for xref to support jumping to the signature in > cases like that is in fact why I made this thread in the first place. :) Sounds like a good goal. >>>>> Maybe the backend could decide what kinds get included in "all". Then >>>>> it could deliberately avoid including anything "reference-like". >>>> >>>> Could we want several such commands? E.g. one for "all definition-like >>>> hits" and another for "all reference-like hits"? With separate sets of >>>> kinds for definitions and references? >>> Possibly, but my suggestion is that "all definition-like hits" and >>> "all >>> reference-like hits" should just be kinds exposed by the backend. >> >> Two different generics returning lists of kinds, or just one? If two, >> then could one give an example of a "reference-like" kind except for >> "references"? I've taken a couple of guesses, but I'm exactly sure of >> them. > > One generic. Just "all-references" is a kind, and "all-definitions" is > another kind. Then how will xref-find-by-kind (or xref-find-extras) decide whether to use xref-show-definitions-function or xref-show-xrefs-function to display the result? >> But if we don't define a dynamic dispatcher at all, it seems we won't >> need the backend to tell us about the supported kinds either. It would >> just support some and perhaps return error for unknown kinds. > > True, in theory we could do that. We could even provide some way to ask > the backend, "do you support kind X?" which could be useful to avoid > making bindings for something not supported by the backend. > > So we could start without xref-backend-extra-kinds, and probably could > get decently far. > > However, I think the dynamic dispatcher is useful for one very important > thing: when the backend adds support for a new kind which the major-mode > and/or core has not yet added support for. Users will definitely want > to be able to use features of the backend that their major-mode/the core > doesn't know about. I thought we might have decided that the backend would create its own specific command for that (e.g. called eglot-find-higher-order-template-cxx-macroexpansion-definitions). We could also create a command for dynamic dispatch. Supplying both is also fine, I suppose, but a little redundant. >>> There's also find-declaration - for Elisp, I think that one *is* the >>> mostly same as find-definition, since Elisp doesn't have separate >>> declarations. (declare-function is kind of a different thing. Maybe >>> find-declaration should jump to the declare-function instance in the >>> current file, if it can, but for now it's fine.) >> >> Yep. Though for cases where there is no corresponding meaningful >> implementation, I would rather abort with an error. Doing otherwise >> seems misleading (like we have special handing of this case, but we >> don't). > > BTW, talking with Joao has convinced me that actually these should be > major-mode specific. So we can have emacs-lisp-find-generic or > whatever, and that can have all kinds of special behavior and a useful > docstring that takes about Elisp things, but ultimately it calls into > the xref backend with a specific kind. Useful docstrings are nice, and I suppose some modes would define their own special commands, but it seems difficult to assign them to the same prefix-map, for one thing. If we use a prefix map on M-', emacs-lisp-mode couldn't add a binding to it without modifying it globally. OTOH, modes can use the [remap] binding, but only when the original map contains a binding and a command that the current major or minor mode is interested in installing a local variant of.