From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Fri, 23 Jun 2023 16:03:26 +0100 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30332"; 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 17:02:18 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 1qCiIk-0007hz-0H for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Jun 2023 17:02:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qCiHq-0000jD-TA; Fri, 23 Jun 2023 11:01:22 -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 1qCiHf-0000hm-1g for emacs-devel@gnu.org; Fri, 23 Jun 2023 11:01:12 -0400 Original-Received: from mail-oi1-x22a.google.com ([2607:f8b0:4864:20::22a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qCiHc-0004ZJ-Us for emacs-devel@gnu.org; Fri, 23 Jun 2023 11:01:10 -0400 Original-Received: by mail-oi1-x22a.google.com with SMTP id 5614622812f47-39ee19cfb77so612370b6e.0 for ; Fri, 23 Jun 2023 08:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687532466; x=1690124466; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0hmPeJXtU9J1fXMs6OfQIWfBdXJ/1kPSc9ZqKDk7r44=; b=gIlAs92/m2oZADYqUu8SPYJkVhIXCl1WiQSW97JmT/vUYST6mMQOBs11roCkxCj018 BI+AY9Y88IDHObqB5OMBLNR+rVcSCKZk8zLKem44kvJYZA/DRkAMpWSTokk5KNYdfFpV CWReJcKQLBVMCLWzrNZy+/ZhY0pCBQNyVbucpDMncvzC9vB9XYlIQ7vM/G9P2xDW0xll DXuiS3ym+fMhROsJVGIs5/8iTVqg0pwUZVQFEtcM3VS4Cka2Iu1kl58+ifMQqStU8Oib p83KIW2lNcAO//mhUDGqxSbHQ9a22z2NMsHBkV4QoNckK/88yLfdKkfjAWluflf0GByI jouw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687532466; x=1690124466; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0hmPeJXtU9J1fXMs6OfQIWfBdXJ/1kPSc9ZqKDk7r44=; b=eITB271fxrOzhgJl7e2XISkyNAkHWsC+ZFLTpjNsZ9YpKEhJZgLBeLOS8KuA3fiNKN 1IlcbVgg8UYhUostBYG8o4RgHXauVUVAfJ4V4W6dhq7AyXo6G+KV3QvGvoAgQEs5R+3d sPV6m4MslXuhiRkP2tgao6JjZt3XzQUpV8wclbfMy6/SIH9YItAb8/FHvBymn1S/rGWH DeBNowtpriCVwx7T+ANLbiglTLXyb4CPgijhfCd+7vCnadOJvW6TjQfYXVav/d+AJhrY YVgyGbwHGs+qmBCwwabmWccdH1VE1uQhJQGrFu87wGqllsAAEfpi6znS9JiuhGhMzkV4 Ep1A== X-Gm-Message-State: AC+VfDyZT6L3g3POa/LZ3txixYw/Ql9imgh/gbzLDhEAxA30U+F/dP7c HUcaoE81iroICqSKSItwNMGU96inSr3kJL1QQfwEQmf4 X-Google-Smtp-Source: ACHHUZ79E1ApShPjTh1IoTQwLH/WyxM//Wte9jWPlLN/MbAwwz8H+SUV6WyVaqyZ/EsdTvoRm5YwWslBjpvr+xAe9h8= X-Received: by 2002:a05:6808:190d:b0:397:f9f2:76b with SMTP id bf13-20020a056808190d00b00397f9f2076bmr30218800oib.30.1687532465902; Fri, 23 Jun 2023 08:01:05 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::22a; envelope-from=joaotavora@gmail.com; helo=mail-oi1-x22a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:307162 Archived-At: On Fri, Jun 23, 2023 at 6:18=E2=80=AFAM Spencer Baugh wrote: > > Jo=C3=A3o T=C3=A1vora writes: > > On Sat, Jun 17, 2023 at 2:54=E2=80=AFAM Dmitry Gutov = wrote: > >> It is of course the prerogative of the backend to choose which locatio= ns > >> 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. Depends on "the way" but yes, eglot-find-typeDefinition shouldn't exist. T= wo possibilities at least and we don't have to implement them all at once. 1. "type" should be one of the "extras" for the new xref-find-extra command= . This is what I think is the current thinking here. 2. if we're willing to add another level of hierarchy to the current *xref* buffer and segregate results by file and category instead of just by fil= e as is done currently. Or make this configurable so the user can segregate just by category. Or present the category as a tag. Many ways to skin this cat. > 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. That is not the SLIME way and C-u M-. already does something else. But I get your point. > (Well, literally C-u M-. won't work, because prefix argument for > xref-find-definitions already is used to cause it to prompt for an > identifier. Yup exactly. SOmetimes this is solved by adding two C-u. Sometimes it makes sense. Not sure here. > But something close to that, perhaps. Maybe this can be > C-M-?) That is xref-find-references. Which curiously, in SLIME/SLY is "find uses" and segregates results by category, hiding the file.