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: Wed, 8 Nov 2023 23:08:17 +0000 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> <65a16247-1b1a-149c-b413-71612f88f184@yandex.ru> <9377bf2b-13ed-8d86-4294-0b88e6808d80@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="38407"; 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 Thu Nov 09 00:09:07 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 1r0rfV-0009jh-FW for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Nov 2023 00:09:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0rf3-0003T4-MP; Wed, 08 Nov 2023 18:08:37 -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 1r0rf2-0003Sl-5z for emacs-devel@gnu.org; Wed, 08 Nov 2023 18:08:36 -0500 Original-Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r0rf0-0004pB-2k for emacs-devel@gnu.org; Wed, 08 Nov 2023 18:08:35 -0500 Original-Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-5094cb3a036so277543e87.2 for ; Wed, 08 Nov 2023 15:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699484910; x=1700089710; darn=gnu.org; 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=+xv1LE1FNbkkDeN5mjVwxAEtODMTxMnXd+rVpP/XuoI=; b=GzI6HWvdFAicWhzDoAtWob01qf070+Uhf3LdCCJb8+wH08Up/SWXqYUZBbKNX9Pi7I P2TbJUdJGY6Vl3JsZf4iqDNhE7rdnJNIOnG+S1eE31B3WZP7ke6urL+I7hAZ62n75Ul3 yhHeNLdFlQ2W4UyDpy8KFXsMBNEnKhfuL4SIVHdR/qeDQ/Rfgyx9vvLW5bqNbKq3sDVV 7DtnKuMj3M/Jj2AY6D9FQT1q05+eOpF+ZGppFsQ9E+pCzdbQEVPWWJCcKFyVQQlwAQZl SxQrGYZfTyw3ZTAPMAQmTnQhA6JwwojMFUD0M1xNmoNirkBliFv3HGUvEmtkCA5mcj8R N8ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699484910; x=1700089710; 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=+xv1LE1FNbkkDeN5mjVwxAEtODMTxMnXd+rVpP/XuoI=; b=McuaJSBqVsn7a0V+FY2SCho3wftie+0UML8k7VybXLvksiTBUN9m0i7+gqw8Q1nomL 6kCqlFVAavW6Yi2X+Wj1Sst3Z1k7xVGhJGBBBQ50s0o/aCaE++KHVsE7pdYXV0UtkH29 kbMl2INZCFMHX2eLop/yDF+6a3NWyi3jiXFuwcWGchcDeY2GO0WDnYyd5wgwknltNqMn i4iyAonsD4PLE9dRQ3GdkjiPvclN58tDenjEU98Sk+TcgvM9hMxF1suOzGCHen/C8KUK uFikEwFLFtAg40iR+dLQbQQyLoSVgSPF+u3zjxVgmdDGMji6JSqkQUI3ivyzDoVYI7f8 zx7A== X-Gm-Message-State: AOJu0Yyd5oc06QfM30FY8dxRaxxvOSdbjf0ZRAblI+mBXyFqb2ukfYfE rfHxXoaSwtWXZ7nVbb5Zmdfdk909JfXsqkXNPUIAxmCdM2GPWw== X-Google-Smtp-Source: AGHT+IGpj5Wq6UwQhYe92wsfv55kAk6LaUyCRrWevxVmHOguhuvlt89Q/OzkxTCOoN1Xf1tf0+vNFKxy+zGwhjrEh+o= X-Received: by 2002:a19:7603:0:b0:507:b074:ecd4 with SMTP id c3-20020a197603000000b00507b074ecd4mr8942lff.7.1699484910023; Wed, 08 Nov 2023 15:08:30 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::12c; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x12c.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:312367 Archived-At: On Wed, Nov 8, 2023 at 5:45=E2=80=AFPM Spencer Baugh wrote: > > Jo=C3=A3o T=C3=A1vora writes: > > > On Wed, Nov 8, 2023, 16:40 Spencer Baugh wrote: > > > > Jo=C3=A3o T=C3=A1vora writes: > > > On Tue, Nov 7, 2023 at 11:18=E2=80=AFPM Dmitry Gutov wrote: > > >> What I meant is, using it with the Elisp implementation didn't > > >> convince me of the usefulness of the feature. Perhaps you disagree? > > >> > > >> Or it would be nice to hear from someone who have tried out Eglot's > > >> integration and found more upsides there. > > > > > > If you want that to happen, the only realistic way to have good > > > feedback from anyone else other than emacs-devel nerds like me and y= ou > > > is to release an Eglot version with this feature, which we can chan= ge > > > later (even non-backward-compatibly, within a reasonable time frame)= . > > > > I tried the Eglot integration, my comments elsewhere are inspired by > > that. > > > > Can you point me to this "elsewhere"? > > Elsewhere in this thread - my message on Tue, 07 Nov 2023 11:51:49 -0500 OK, I found it. It's useful, and very commonly done, if you CC the participants in this discussion, particularly when addressing their contributions. Your emails are sent only to emacs-devel and it's easier for me to miss them. > > I found it rather clumsy out of the box. > > > > What exactly is clumsy? Please state the command you used and what the = clumsy effects were. > > Specifically xref-find-extras is clumsy, because it's annoying to have > to type the full "kind" in to request a specific "kind" of definition. I don't find it annoying. But since we settled long ago that there can be no standard set of all kinds that makes sense for all languages, then I don't see a better way than what the current xref patch does now: asking the backend for kinds and then having one command with an additional select= ion step. The little change I did to Dmitry's xref.el allows particular modes such as Eglot to implement their own "quick-access" commands for a particul= ar kind more easily. > eglot-find-{declaration,implementation,typeDefinition} is good as > always. Right. And they're not going away anytime soon. > > > However, it works well with an > > approach of adding bindings for individual kinds, as is currently how = I > > (and other Eglot users at Jane Street, and presumably most other Eglot > > users everywhere) use Eglot. So that compatibility with an > > already-common approach is an upside of this integration. > > > > Bindings to what commands exactly? > > eglot-find-{declaration,implementation,typeDefinition} > > > However, the alternative UI which shows all kinds of definitions in a > > single buffer does not exist for Eglot in the same way it exists for > > Elisp. So... I can't really compare it to that. > > > > What "alternative UI" are you talking about exactly? How can I trigger = it for Elisp? Please give a full example as I don't know what > > you are taking about. > > In Elisp, M-. (xref-find-definitions) already shows all the kinds of > definitions that are requestable through xref-find-extras. But there's > no similar way to show all kinds of definitions for Eglot - M-. only > includes the proper definition, not the declaration and typeDefinition > and so on. As it always did. And you yourself wrote > 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. And I fully agree, btw. So I don't understand why you sometimes want prompting and sometimes no prompting. But you can discuss that with Dmitry about the UI parts. I'm just really interested in the xref.el <-> eglot.el API. I want it to be as simple and versatile as possible, much like it is now. > I know you would prefer not to implement such a thing, I'm just > explaining for Dmitry that since this kind of UI doesn't exist, I can't > compare xref-find-extras against that kind of UI for Eglot in the same > way that I can with Elisp. It's not really about not wanting. It's an incompatible change. Users used to M-. on an identifier and going to the definition would now see an *xref* buffer to click on. And it would break the only command where C-u M-. to prompt for the identifier first can possibly work in LSP. But, I think your idea that passing nil (or 't' or 'all') as KIND to xref-find-extra makes it ask xref-backend-extra-defs (which should be renamed to not have that misleading "defs") for all kinds previously reported by the backend in xref-backend-extra-kinds. Then the UI can organize the results as it sees fit, and I don't have any strong opinions on how it should do that, nor any strong opinions as to how many C-u or variables should modify the new command behaviour. That's not to say I don't have opinions, just not opinions strong enough to justify not pushing a draft version of the current patch into master. Jo=C3=A3o