From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Fri, 23 Jun 2023 17:53:21 +0300 Message-ID: <83ilbe1b8e.fsf@gnu.org> 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> <81c2ff07-c5e2-fb3a-5945-049a307bff84@yandex.ru> <835y7e3etn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26218"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 23 16:54:05 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 1qCiAm-0006Ze-VL for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Jun 2023 16:54:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qCi9v-0004TJ-1O; Fri, 23 Jun 2023 10:53:11 -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 1qCi9t-0004QO-98 for emacs-devel@gnu.org; Fri, 23 Jun 2023 10:53:09 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qCi9s-0007Z1-KE; Fri, 23 Jun 2023 10:53:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=SkxtisXidvhBaVeKrWTLlL/TwCa7WR2OKlibpERAPC4=; b=Ck+YdAPk4BfSoKTxkkRr InUh2qNYKKn82xHAeoGeoCxpKGjapDUXhMb3pnPbdkihyp3Qgg/le7wqojytgccd2vLruPgJW6xtH Ds2vkijhcX2esxCPQItC+rYFwWNC1e24Psnfly5reYWkphxw6alNGye2wPfQHDAGHYXi5WR60xpWS oHkntwgYfETuqzpMjQroksiH5bp6Krkr7m9wzh+2v/4FDvg5tN5k6fQaOsfQK1rQ1StijRLG0B1zU FLg6CSFUO6VxKAd4VYLAXAB9hNoUOq5KZ0wnuFLdKbb/pHLF+zUBlZvTPqnmRKCvApxqXo/uAxHO1 XTkqlsbcsXVESQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qCi9s-0002eB-1g; Fri, 23 Jun 2023 10:53:08 -0400 In-Reply-To: (message from Spencer Baugh on Fri, 23 Jun 2023 10:37:30 -0400) 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:307160 Archived-At: > From: Spencer Baugh > Date: Fri, 23 Jun 2023 10:37:30 -0400 > Cc: emacs-devel@gnu.org > > On Fri, Jun 23, 2023 at 1:52 AM Eli Zaretskii wrote: > > > > > From: Spencer Baugh > > > Date: Thu, 22 Jun 2023 15:22:25 -0400 > > > > > > João Távora writes: > > > > On Sat, Jun 17, 2023 at 2:54 AM Dmitry Gutov wrote: > > > >> 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. > > > > > > > > I see no problem with that, but it might be interesting to keep the > > > > backend plug-in mechanisms generic enough to eventually enable > > > > different types of UI. > > > > > > Do you envision that eglot-find-typeDefinition would also be covered by > > > xref-find-definitions in this way? The type defintion feels a bit > > > different from others. > > > > > > In any case, it seems to me that C-u M-. would be a good way to say > > > "return all different kinds of definitions" to xref-find-definitions. > > > Then the user could just switch to the one they want in the *xref* > > > buffer. This keeps the basic M-. operation fast, while making it easy > > > to jump to other kinds of definitions. Seems perfect. > > > > Why does this need a separate key sequence? M-. already knows how to > > cope with more than a single candidate returned by the backend. How > > is this case different? > > Merely that M-. currently usually returns only one candidate, and when > it returns multiple candidates it pops up a buffer, which is annoying > if you only ever want one of the candidates. Isn't that what you wanted when you said "return all different kinds of definitions"? M-. shows a buffer with several candidates when it cannot find only one that fits the name you typed. That is rare, but it does happen. AFAIU, you have described one situation where this will happen. So I think the behavior of M-. is exactly right in that case, and we don't need any new key sequences or commands. Or what am I missing?