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: Sat, 17 Jun 2023 04:53:44 +0300 Message-ID: <81c2ff07-c5e2-fb3a-5945-049a307bff84@yandex.ru> References: <865ybmu2ha.fsf@stephe-leake.org> <39e25c9a-b4cc-a0ce-3f2a-1d2a1fc243d0@yandex.ru> <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="12473"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cc: Eli Zaretskii , stephen_leake@stephe-leake.org, john@yates-sheets.org, rms@gnu.org, fgunbin@fastmail.fm, casouri@gmail.com, emacs-devel@gnu.org, azeng@janestreet.com To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 17 03:55:00 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 1qAL9Y-00032d-6L for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Jun 2023 03:55:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qAL8g-0005Nq-5k; Fri, 16 Jun 2023 21:54:06 -0400 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 1qAL8d-0005NN-UN for emacs-devel@gnu.org; Fri, 16 Jun 2023 21:54:03 -0400 Original-Received: from forward501b.mail.yandex.net ([2a02:6b8:c02:900:1:45:d181:d501]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qAL8b-00058k-LY; Fri, 16 Jun 2023 21:54:03 -0400 Original-Received: from mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net [IPv6:2a02:6b8:c08:a497:0:640:fcbf:0]) by forward501b.mail.yandex.net (Yandex) with ESMTP id 53EE35E972; Sat, 17 Jun 2023 04:53:53 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id nrSKaxHDWOs0-WMRPB8cA; Sat, 17 Jun 2023 04:53:52 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1686966832; bh=Dbnq+8IhU5qErxYXkpmnCOhZwE9Igmu3qeyz8zo0ImA=; h=In-Reply-To:From:Subject:Message-ID:Cc:References:Date:To; b=xFF4SMgRm/1GlATemD9JK1T7URT4E8PpdkGSLUCHhR6Gs7VSAG3b4DxHD+gdR3jkD RMvC2Op0nbWBWzF0LEE8KcEeJrsX/bsW7IOsOXCqn/8uvFF4G8NlAlWywKrm+Hu1pq AUVOl2vfLtqCqqrrZ+ZKzocYiKOjew9HYX5GSgGk= Authentication-Results: mail-nwsmtp-smtp-production-main-36.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 785F327C0054; Fri, 16 Jun 2023 21:53:49 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 16 Jun 2023 21:53:49 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedviedgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegughhuthhovheshigrnhguvgigrdhruheqnecuggftrfgrth htvghrnhepffelkeeuhfegtdekveefffelhfelteeluefghfegvdejudeuvdejtefhvefh kedunecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegughhuthhovhdomhgvshhmthhprghuthhh phgvrhhsohhnrghlihhthidqudeffeefleelheehvddqvdelgeejjeejjeeiqdgughhuth hovheppeihrghnuggvgidrrhhusehfrghsthhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: ib1d9465d:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 16 Jun 2023 21:53:46 -0400 (EDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a02:6b8:c02:900:1:45:d181:d501; envelope-from=dgutov@yandex.ru; helo=forward501b.mail.yandex.net X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.093, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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:306847 Archived-At: On 17/05/2023 00:10, Spencer Baugh wrote: > An option I didn't mention originally: Perhaps xref-find-definitions > could just show both implementation and interface. That would remove > the need for any new keybindings. The UI might be worse but perhaps > it could be improved. > > This is inspired by this comment: > https://github.com/joaotavora/eglot/issues/302#issuecomment-534202561 > > The relevant excerpt: >> By the way, on a tangent, I think it's a mistake on LSP's part to >> import C++/Java's ecosystem of possible symbol loci. In Common Lisp, >> there are many different types of construct associated with a symbol >> and they are all "definitions". A good IDE like SLIME will use >> something akin to xref-find-definitions (indeed xref is modelled after >> SLIME) and categorize them properly in the result buffer if there is >> more than one. So the command should have been textDocument/definition >> with some kind of subtype parameter, or at least this is where xref >> should evolve to, i.e. xref should keep the single command >> xref-find-definitions and maybe augment it with some "definition-type" >> parameter. It is of course the prerogative of the backend to choose which locations to return as the list of definitions. Some backends/languages might as well include interfaces in the list. One problem with that, though, is that we're doing some things differently from SLIME. In particular, we try to make it easy to jump to a specific definition as quickly as possible. If there is just one definition found with a given name, we don't even prompt to choose. We also have an option for xref-show-definitions-function like xref-show-definitions-completing-read which also tries to make things faster using completing-read. If other kinds of locations are added to the list, the odds of getting duplicates get higher, slowing down the interaction. So it's probably a good idea to hide some location kinds behind prefix argument, or a separate binding. That brings me to another question, though. Can we assume that all "extra" searches should be of the "definition" type? Meaning that the results display should go through xref-show-definitions-function and not through xref-show-xrefs-function. If yes (and the ones that have been brought up in this discussion -- "implementations", "declarations", "type definitions" -- seem to fit that pattern), then good.