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 16:04:26 +0000 Message-ID: References: <87il697r5g.fsf@catern.com> <87r0kw8nxu.fsf@catern.com> <3fe5a8cd-b355-d7eb-10ad-8846aef3387b@gutov.dev> <878r6mx1xc.fsf@betli.tmit.bme.hu> <90e4b9a7-3b51-587d-e317-b89e5d5464d9@gutov.dev> <87sf4scxax.fsf@betli.tmit.bme.hu> <9ac758b8-5fb2-9b3d-7947-96777694e3e0@gutov.dev> <2fe6c4f0-dffc-ce00-758e-0c431a803d4d@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="2469"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Felician Nemeth , Spencer Baugh , emacs-devel@gnu.org, Eshel Yaron , John Yates , Ergus , Filipp Gunbin To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 27 17:05:21 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 1r7e6q-0000Lo-9x for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Nov 2023 17:05:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7e6F-0002Po-Md; Mon, 27 Nov 2023 11:04:43 -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 1r7e6E-0002OK-HM for emacs-devel@gnu.org; Mon, 27 Nov 2023 11:04:42 -0500 Original-Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r7e6C-0001Gm-Ny for emacs-devel@gnu.org; Mon, 27 Nov 2023 11:04:42 -0500 Original-Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-507ad511315so6128641e87.0 for ; Mon, 27 Nov 2023 08:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701101079; x=1701705879; 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=2W2zHBQqSLrLVu2OWWiFCq+7smis72xKWHaqccBqaPc=; b=F6gw50VqfzNnIO4+iclRXlSFN6qLpYEB7GqQhtUzkKsKfJa31rdoj2qQTQFi+mXSS2 Rtn3y2cmCEcfaJ6UNr661vcBTcF6sXRU0JNScJcVgT7YawjR8oyHfEKOmQifaiVPRuLJ OxDTZKawTETpI8BkGScmBNigrXqQlIb6APUx5oHi4xTW62UFMUomEMaEfQ6h6wf94tsm dx2o0vso7lBjeZydAnhV4qXIXQeQZtcQzYXPP4xZ8QmuwPCLXO+SI7wumN4Ip0cNg/Y6 aFIn9AyGkyXdnG552TeKaJjtwI9CWhQWahJ7O+bw/tCzhRakWU95KKgx2cpLVOAGvWGH dSEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701101079; x=1701705879; 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=2W2zHBQqSLrLVu2OWWiFCq+7smis72xKWHaqccBqaPc=; b=sPPNUGoQJmV3SYVdrUKguEf9VYwLcSTugM4/ZNGOrNYXooZZFMJwsKZ2pNQQRDrDTz puecOULE8Tk8/BWJz1i7UPSgpU3dHIecZiG2/jT4heNHdpBN0PvTKpk4Hyo9XNz5SO4z I3us1vzs3rc4YCUjxI4NxozTfgSKW+eZw+ba1gxL8NfboqS4CftYrJkd08YBqCrSUo6H saN9WF9v30YoFmtM6ER5wIXpbH9NNDU0+WPAA8wZk1QK7a+1kLBHWVRXTj6fc8TU8GK5 kIROMumuOsvfY3XCo079nEfTR2qf5YVlFytge1Yya1WMJpzxOXxEBxfhQJFhRjsGU8uK oiUg== X-Gm-Message-State: AOJu0YxBObdi3OsshTUgoZpcZw76htMdLFh8enYawqmElwURtvNX9K2O mYCBKqAOuO+sD0ArWrT1pXPtoabDdlhPxEPjtk1r4cRegXA= X-Google-Smtp-Source: AGHT+IEY5DDtFH9MevZ+P5LTxoKEArelwqV40cX1vkk15sgd24Wpic4YJr2FM8pk/NyqWjM2M2DAyLXcGgHrjKftAt0= X-Received: by 2002:a05:6512:2389:b0:506:899d:1994 with SMTP id c9-20020a056512238900b00506899d1994mr7532461lfv.52.1701101078599; Mon, 27 Nov 2023 08:04:38 -0800 (PST) In-Reply-To: <2fe6c4f0-dffc-ce00-758e-0c431a803d4d@gutov.dev> Received-SPF: pass client-ip=2a00:1450:4864:20::136; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x136.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:313280 Archived-At: On Mon, Nov 27, 2023 at 3:45=E2=80=AFPM Dmitry Gutov wro= te: > That didn't answer the above question. To signal "what kind of > cross-references it can find", it would define > xref-backend-definition-kinds with corresponding return value. The answer was in the first two words. "Of course", and the reason is in the words following that. So to be clear, yes, c++-ts-mode, if it ever gets such capabilities should define c++-ts-find-declaration, c++-ts-find-partial-specializations and so forth, but probably no c++-ts-find-implementation (fuzzy concept in C++). It should (or rather, it may) bind them in a given xref-provided prefix map and they should become active when c++-ts-mode is active. For "references" and "definitions" the existing xref commands will do, but the phrases "references" and "definitions" should well be in the "prompt for kind" list as options. And no, it doesn't take much imagination to do this for CC-mode as well, if the backend supports both C++ modes. > > The major modes could do that, for example. They could do it by > > linking the backend-created "one key/command" keymap into a special > > prefix created by xref.el, doing so by calling a load-time xref.el help= er. > > Okay, so we would create and occupy a new common prefix. But without any > commands in it? How do you suggest we advocate for that around here? What's the difference between no commands and useless commands that return errors? But you could put the existing xref-find-definition and xref-find-reference= s commands in it. Even the "find-all" could be there. Also, as far as I can see, you are already ogling the M-' binding in your branch anyway. > > So maybe some backends would have d for "documentation" and others wou= ld > > have d for definitions, so what? Maybe that's precisely what a user wor= king > > on a documentation heavy system expects "d" to do. And if these two bac= kends > > happen to be enabled simultaneously, even this conflict could be > > resolved, by adjusting the keymap during the linking process. > > That's easily solvable in other ways. OK. I just suggested one, keep it in your catalog maybe. > And I didn't just invent the need for faster interaction by myself - > just look at the first responses to the prototype. Okay, perhaps some > power users in this thread don't mind adding personal tweaks to their > config to speed things up. But that means the OOtB experience will be > lacking. I'm not saying the bindings issue isn't important, I'm saying it's (1) secondary to the communication mechanism and the functionality which is already pretty useful in your original patch in this 20-years+ Emacs user's experience (and I don't keybind things). (2) not something we should rush to solve by copying an awkward categorization that doesn't fit the needs of languages. (3) solvable in all practical aspects by judicious coordination with backends and major modes. > > It's much more pressing to decide if/why you want a command named > > xref-find-all-definitions to return things that aren't "definitions" > > by any measure or what is pressuring us to enshrine > > "declaration/implementation/typeDefinition" in one of our > > most generic libraries. > > It's a framework, not so much a library. Although it has the latter's > capabilities too. As a framework, we should consider what the end user > experience would look like. Sure, of course. And it already does that it excellently in so many good ways (IMHO the decision to copy SLIME's UI was excellent). But don't try to make it the uberframework for finding things to the point of making Emacs-wide commands copied from LSP that don't fit a bunch of the vast amount of Emacs use cases. It's too heavy handed, a step too far, not elegant. Jo=C3=A3o