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: Thu, 9 Nov 2023 02:08:39 +0200 Message-ID: References: <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> <54cb435f-4d51-4c0d-43d8-2991dd7ee6bd@gutov.dev> 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="6285"; 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 Thu Nov 09 01:09:40 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 1r0sc7-0001SO-Fh for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Nov 2023 01:09:40 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0sbK-00042w-VD; Wed, 08 Nov 2023 19:08:51 -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 1r0sbH-00042e-Nj for emacs-devel@gnu.org; Wed, 08 Nov 2023 19:08:47 -0500 Original-Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0sbF-00080E-60 for emacs-devel@gnu.org; Wed, 08 Nov 2023 19:08:47 -0500 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 53FD03200979; Wed, 8 Nov 2023 19:08:43 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 08 Nov 2023 19:08:43 -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= 1699488522; x=1699574922; bh=26tEY4Z4HA5s0kunYxD6bPdflIeZCiAKGnQ BB58f/zQ=; b=C18GoN9xn8OjbDoNnevdeu0+3NwCLTHaImeE2kbZFpu6k9fqVJ9 /r16m5LdwVqzZlKEEUmcMEPIbQAcKFOU0Ry9SrZp9MxsWIosbc8u/1p4DZR5wAFY bc7xHi9dM2yHykVSyteZUYbRqaL6ROpGXwWKGb/AFTNfKiNzKECs3K8wFDBC1+KE cDgT6qhwduxWbQndBdHBdpVO5m7BEGuR8asmMtZMPHoRpLlbJZ2RnyMLSjo6ckZ9 /66pSNORGuVMmDtb/r74/rXDBnzue+rxEgEhHrtjW5o6abgmyBsrZDR1Hllq4Uwq YjjxljJVhyEjNJkJZH65dSOAZet/pp4ZaaA== 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=1699488522; x= 1699574922; bh=26tEY4Z4HA5s0kunYxD6bPdflIeZCiAKGnQBB58f/zQ=; b=n DLwGtDijWBLmZHjbXVY/Z2Uw1W47lKpKlPO7DD7IVSuVYvAKB9HEqZB98qmR50O5 ZsqAYIBxM9VJP++imtpvKUI+jPayPm+cTlR4afHsrAME9ZW1PqZZ487HiqQDtv1E STTK74Bl/xZ+36HZGbOMTxQgHuwhlPUJEtaqoH0N1JrSjp67wndETgMi+TPBjpmP UX4pmgHgbNRXNMecAUrHl7pmTLUsgrHSB2IbGLSX/F4ZHgEjByr6clD998GoBvVm 4jSphoHlz09Q+CvxWkyvJifNQyY416dT0MedzSa3rOOb9KjHDEGQbc22UOKXHWBr 5NsSCgi1MqfvT7MOH4cRw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddvtddgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeghedthedujeeiteeutddtjeekheejteeukeehffdutdejuedvfeevueeviedu udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Nov 2023 19:08:41 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=64.147.123.21; envelope-from=dmitry@gutov.dev; helo=wout5-smtp.messagingengine.com X-Spam_score_int: -60 X-Spam_score: -6.1 X-Spam_bar: ------ X-Spam_report: (-6.1 / 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.277, RCVD_IN_DNSWL_LOW=-0.7, 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:312371 Archived-At: On 08/11/2023 19:25, Spencer Baugh wrote: >>> 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. > > As in, xref-find-definitions (M-.) *by default* shows all kinds of > definitions? That seems bad for one big reason: 90% of the time, in 90% > of languages, there's a clear meaning of "definition" and I want M-. to > take me there directly rather than prompting in any way. But there are > other kinds of "definitions" which plausibly I could want, just > sometimes, not by default. Fair enough. So "definitions" are the places we want to see 90% of the time when learning about a funciton or a variable. And the other reference kinds (BTW, what to call that? "definition kinds"? "reference kinds"?) must be apparently less useful. Do you know which category does "eglot-find-typeDefinition" falls into, and why? Aside from the fact that it, historically, uses a separate endpoint. > If you mean something a non-default version of xref-find-definitions, or > another binding for another basically-identical command, sure, I think > that would be good. We can have both that command *and* have a command > which prompts for KIND and defaults to "all". 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. >> 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". > > True, interesting point. I wonder if we could reasonably distinguish > "definition" kinds (a small number per identifier) from "reference" > kinds (no limit on how many per identifier). OTOH, maybe "declarations" are a little closer to "references"? E.g. in Elisp the declare-function forms seem to be more in that category. And if we're talking about C/C++ forward declarations, I suppose that depends on whether the declaration is for an "extern" > Although I suppose there's > also no limit on how many implementations of a generic function there > can be, and that's definitely something that fits in "definitions". The fact that there are often many definitions for a generic function indeed is an argument toward including more "kinds" into xref-find-definitions' output by default. But only as many as it would be actually useful, especially if the kinds are mutually exclusive (a symbol is either one or the other) or intersect very rarely, or can be distinguished by context. > 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? >>>> 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. > > Hm, why do you say this? This approach seems very extensible to me - > modes could add their own bindings/commands/kinds for things specific to > that mode. But they build on top of a set of common kinds which are > provided by the core, which don't vary between language too much. It is less flexible because any time a backend wants to use a new "kind", it will need to expend some effort and add it to the core somehow. Define a new command or two and assign them to the said prefix map. This could also lead to conflicts if backend authors don't do this carefully enough. > I do think that if we go with an API which has any notion of "kinds", we > should have some standard "kinds" in the core like implementation, > declaration, type-definition. I don't see any reason not to do that. We could have a "registry" of kinds, associating each of them with a key. Then the result could be more dynamic, e.g. M-' could be bound to a command that reads the key and performs the dispatch to the corresponding search (similar to project-switch-project). And the users (though probably not packages) would later be able to customize that mapping, adding new kinds or modifying the keys. With this approach we don't end up with many xref-find-xyz commands, most of which just clutter the namespace, staying unused for a large proportion of the users. OTOH, one wouldn't be able to examine the prefix map and its contents and definitions with (M-' C-h) -- that's a minor reduction in usability. >>> xref-extra-kind, prompting for kind: M-' M-' >> >> Would we need this command, if we had separate commands for each kind >> already? > > This would support kinds which: > - are language-specific, > - or are more rarely used and don't need a dedicated command, > - or are both. What would be the more frequently used, less language-specific commands? If we could agree on such list, we could indeed have those xref-find-a/b/c definitions and a command with completing-read for the rest. >>> 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. > > Most languages have something that can fit into "declaration" or "type > definitions", though. > > For Elisp generics, find-implementation could show the cl-defmethod, and > find-declaration could jump to the cl-defgeneric. I would love that, > actually - I already find it rather annoying to have to navigate in the > xref buffer to the cl-defgeneric when I M-. on a generic method, if I > know up front that I want to jump to the cl-defgeneric. Interesting. I usually find cl-defgeneric entries to be useful in that list. But we *are* able to distinguish those that don't contain the default implementation. > Actually, this example has just convinced me that I definitely want > "kind-specific commands", even for Elisp. That would be great. > > For functions without separate declarations, find-implementation and > find-declaration could jump to the same place. In some languages, maybe > that's just always what happens. Aren't find-implementation included in find-definition anyway? Or *are* the same as find-definition, for example, in LSP's approach? Aside from the fact that the latter also works for variables and other symbols. > As for type definitions - even Elisp has things that could reasonably be > called type definitions, we just don't support jump-to-definition for > them right now. I have no idea how we'd implement it, but we could > support jumping to cl-defstruct definitions, for example. Maybe we > could use information from native compilation to guess the type of the > identifier at point? But anyway, for now we'd just error if the user > ran such a command in emacs-lisp-mode or other modes that don't support > jumping to the type definition. I think the aforementioned type definitions in Elisp would be better included in the "find definitions" set because they generally don't clash with other kinds. >>> - 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. > > I almost want to say that we should have it be a prefix regardless of > whether we have separate commands for kinds. I guess it depends: You probably meant "have it be the binding". > - if we use C-M-?, that's already such a hard key to hit that maybe it's > okay if we bind it directly to a command > > - if we use M-' or something similarly convenient, it would be really > tragic to not reclaim all that premium keybinding space. It's possible that it would work better the other way around: if we discover that people really want a prefix map, then it would be easier to argue for an easy-to-hit binding like the above. > (And > probably if we use M-' we will need to put the old command on > something under M-' anyway) I think it would be odd to put an 'abbrev-...' command inside an Xref-specific prefix map. But I suppose reserving the "M-' M-'" sequence for this is not out of the question.