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: Mon, 27 Nov 2023 15:45:50 +0000 Message-ID: References: <953056ea-9cfb-34ad-6515-9036633dfdbb@yandex.ru> <2d964697-2b4e-64c7-2f16-aae87e57def4@yandex.ru> <87il697r5g.fsf@catern.com> <87r0kw8nxu.fsf@catern.com> <3fe5a8cd-b355-d7eb-10ad-8846aef3387b@gutov.dev> 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="24068"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Spencer Baugh , emacs-devel@gnu.org, Eshel Yaron , John Yates , Ergus , =?UTF-8?B?RmVsaWNpw6FuIE7DqW1ldGg=?= , Filipp Gunbin To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 27 16:46:51 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 1r7dow-0005zr-GK for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Nov 2023 16:46:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7doO-0001o5-RR; Mon, 27 Nov 2023 10:46:16 -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 1r7doM-0001k6-1M for emacs-devel@gnu.org; Mon, 27 Nov 2023 10:46:14 -0500 Original-Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r7doE-0006Hn-2n for emacs-devel@gnu.org; Mon, 27 Nov 2023 10:46:13 -0500 Original-Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-50baa7cdf6dso2691483e87.0 for ; Mon, 27 Nov 2023 07:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701099963; x=1701704763; 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=aTH3oNj9giu5vJhKy+C0DLv01BD5yzHarvV60doVoj4=; b=ncKXYazaWgY5pYRaVc0977h3RK/EK59cLD2uboRLf9rq5K/2NM1YsFZtrHsxyT4wNE qrOxCbBoiaiR6KpjQ/xolREVKklG5TOaf4mfLDobsJjs7HnKgOYOh8rTxz76mubYcPOL 3jWVpGtoPflilnf4jGvRmDPJwWXc8Cz/AMaVrfSDeEcUKG2SGf3W/lyvxeZdVisx5U0m ZYHK56EGlMs7gja7F18wQPDu83vPYNXHvj0Gnd7IC1YACKdeVRz/63PshSsQZDMl/K// T2Z+wV83g5FtEvPIa33PHjUtkS1hdVBUv2aORHGs6bYcEPy9gdYN7YBI9enljh9HrXzm I9qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701099963; x=1701704763; 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=aTH3oNj9giu5vJhKy+C0DLv01BD5yzHarvV60doVoj4=; b=GVUY/clHCZH5L9J+evG1WjXe8QO6oX+LXmb+EJPb9B1CoWF0tgSdrvRVlwge5KEFdU KHu/vWpQhvhHM6/PuL4jnMYMRY9XAH2+/coCRAGOW65UEKMgkknLBXTSZobd/iTcNhVb //Pcxt9qNy8UJwm5qcFgg3enHJsfcXup3xbPtcrxj2lGsBe6MBfI0a/y5YF2xBXAsYdp 4sNrGUswbQOJnJxKte4yX7EJtrFhvgUHskYx5jukhXrWwWZRssi8ts42DMOR29RGW8Pi lTirsh8J45TOs0DgKZwXTjU/lkiGqlqXjoQUCYzmA2wDm7kp5VjLEjSxR3dztZ64AGNe N/0w== X-Gm-Message-State: AOJu0YyeL41yAspC3DTnHznY5wagEJfYKBuQHyfoukXlJzLLG99Xu+et V258Podp/PmIKWmG4IOi08+c4hVM2VykQ2WcLgc= X-Google-Smtp-Source: AGHT+IEBH1TukrxTplPvm3ThCbVV+NE/kf+Vj++tkrnE0C6YF6e3LpZHGg5S32mwHyUL7wnEpHc0+5fobqTcg6lq6a0= X-Received: by 2002:a05:6512:1054:b0:50b:b588:e5b1 with SMTP id c20-20020a056512105400b0050bb588e5b1mr1220017lfb.24.1701099962682; Mon, 27 Nov 2023 07:46:02 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::12f; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x12f.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:313278 Archived-At: On Mon, Nov 27, 2023 at 3:17=E2=80=AFPM Dmitry Gutov wro= te: > > In my view, again, we should not limit ourselves to a triad > > of kinds clumsily inherited from LSP. We should limit that LSP > > concept to Eglot. It is not flexible enough, because it can't > > be. But Xref is for much more than LSP. > > What it seems you are saying is that we never should try to extend the > set of definition-finding commands above what's already in xref.el. Not necessarily. I'm saying we shouldn't make that a priority or the rest of this useful feature contingent on that. If we someday come to the blissful epiphany that every language ever to be and to have been has the fundamental concept of a watermelon in it, then we can think about xref-find-watermelon. > Because it seems clear that we're unlikely to find a more > widely-supported set of additional kinds that the aforementioned triad, > in any medium-term future. They're not particularly well supported, they won't age well. LSP uses that trio for two reasons: it doesn't have major modes or a programming language, and it's driven in part by commercial vendors of specific large language implementations. But Editors like VSCode still have "plugins" akin to our major modes. I wouldn't be surprised if these plugins don't have total freedom over what part of LSP they expose to the user. Opening VSCode on a C++ file for example, I see "find definitions" and "find references" have dedicated bindings, but "declaration" and "typeDefinition" do NOT. And "implementation" isn't even there as it doesn't make much sense in C++. > >> Like now, for example, many will likely stay with CC Mode for a while > >> because of it more lax behavior in macro-heavy codebases, where > >> c-ts-mode chokes and shows syntax errors. > > > > Whatever you are suggesting, I don't understand. Whatever xref backend > > is written for c++-mode with its special-purpose commands for finding > > C++ things can be used for both c++-mode and c++-ts-mode. Just put tha= t > > code in a special file. > > What about default key bindings? I've already answered that in a nearby email. > > I think this is a mistake and a regression from xref-find-extra. > > The command should be called xref-find-all, xref-find, or simply > > xref, since definition is a category that doesn't span a lot of > > useful cross-referenceable constructs in many languages. In C++, > > for one, a declaration is absolutely _not_ a definition. > > It's a "definition" in at least one Xref-related sense: it should be > dispatched through xref-show-definitions-function. So it's a "definition" because the xref.el author called an implementation detail a "definition"? What does the user possibly care about that? > Further, I'm not sure that when a user looks up all definition-related > things for a symbol, they wouldn't want to see the "declaration". In > fact, if we classify 'defgeneric' as declarations and 'defmethod' as > implementations, I'm pretty sure I would want to see the former in the li= st. Of course, if the world is painted in the three LSP primary colors, every other color will have to be truncated to that. But it doesn't mean the world gets any prettier. > And you yourself mentioned that "type definitions" might be suitable for > that list (which I found surprising at first). So it seems clear that > there is no single red line. Precisely. So don't go making those lines. > o show me "references" as one of the kinds of thing to search for. > > Then the list of results would drown in "references", wouldn't it? But if I want to see references to the given symbol at point, that's what I want! I press M-? xref-find-references all the time in Eglot. > For experimentation. Then perhaps we could cut another less contentious branch off 279203199a2d10677e42747476b39394a4184a78 Over that branch we can rename Eglot kinds to strings and "extra" to "all". I'm sure that's less contentious, a good candidate for master and not incompatible with evolving into whatever results of your experimentation. > > If you are proposing this is brought to master for experimentation, > > and if you are wary of this step, then may I suggest we push the older > > more conservative version, perhaps with some naming changes? > > I'm not yet seeing a common basic version for which there would be > agreement. You just called a renaming a mistake and disagreed with the > principle of what "definition kinds" should be. > > > This new version isn't something we can roll back easily, while the > > more conservative approach could eventually be enhanced with the three > > "popular kinds" later on. > > I'm not proposing any merge to master yet. Well I am, but not of that code, at least not yet of that code. Merge to master something useful that doesn't compromise us. > >> What does everyone think? > > > >> xref-find-all-definitions is an interactive native-compiled Lisp > >> function in `xref.el'. > > > >> at point, prompt for the identifier. Interactively, show matches > >> for all supported kinds. When invoked with prefix argument, > >> prompt for KIND. > > > > I can't get this to work btw. If I add a prefx argument, it > > prompts me for the identifier, which I don't want. > > What's what the docstring says, and it's what Felician brought up as a > problem. Do you want two separate commands? And one of them would always > prompt for the kind to use? No, it's not. It starts prompting me for identifiers which for LSP is useless. Eglot has no way to know which kinds of reference it has for arbitrary identifiers not at point. The only useful way for this to work in Eglot would be to prompt for KIND and _then_ show the results, which may be empty. Anything else doesn't make sense for Eglot, for LSP-specific reasons beyond my control which I've already explained. Jo=C3=A3o