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:41: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="2799"; 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:42:35 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 1r7egs-0000X3-CD for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Nov 2023 17:42:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7egD-0004WH-SP; Mon, 27 Nov 2023 11:41:54 -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 1r7eg3-0004Vc-2q for emacs-devel@gnu.org; Mon, 27 Nov 2023 11:41:48 -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 1r7eg1-0008T5-BO for emacs-devel@gnu.org; Mon, 27 Nov 2023 11:41:42 -0500 Original-Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-507bd19eac8so6078439e87.0 for ; Mon, 27 Nov 2023 08:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701103298; x=1701708098; 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=A2DLC7wWg2CuneEEdgfuBveYf5kQjm2xLBTfLIBaM+c=; b=AHEE+9OO7Cn79GMBCQ1Pkq1tf6YedkU5HBou9ZWcNPrvRS70CyZt7JLVPjj+gqK+xa mcyyhEAlS08suC6zJGJ11xtuWjUrRU1DSlGYvS42MtHacJABdQXV1KLMigqvrbrZm2X/ 7Xp7SycgVSELimT7w7oPUUuTBUuEBFGbxNL2ewnE5xVm404p6CLWf55yuidvXmbgkhRI 4jNaT8PfuXR1NFX4uS7RWIcbtdNGPxpufHnCvZDGUlBVR+/EtmVZQ5PgtofI8U/t9FUG Ybk4/bWrNvuswqxIBfTURvJSI1p/qHuCRGm57kjxzFi4ga6zx9et4PGpeaLoCwXIIbMD BDCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701103298; x=1701708098; 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=A2DLC7wWg2CuneEEdgfuBveYf5kQjm2xLBTfLIBaM+c=; b=LLLOEpWhop0LzCGPsR4NIEXzF4ZNpRqL4ehccwpd+tRT7LEidzarK96Ljy4k7hIcjC gu47EiRZnx0e7KHrkzgZ3RDHlHBsuuLJeCYFwqGYptTMPFkOCJOeGmTW/qH4rPem8XNK l1dB/yH03XMwOEr5bWZVDa6DVvil6PT8Wop0fXzqMLBqTxtxV7+AsMtzvDPS91cwTjpx dlC9k0Fh84hxFAzHOGrrjEGicz2ckv9KY0n1gW3ZE8qdncuHhzHb9/eBsnw9DgJbkZva G1mbm44M3VF5JxRcCHI07bX0ERbmjCkg+fcX7R5q8/+/Uu34U9Gt42X/Zo0G4h07WKxF JOpg== X-Gm-Message-State: AOJu0Yz05R9BQrRXNpXvvd9U09Hpa0En9xU7OZ9bIs65oRpJMbHoRUyo 8An3B06dfNOjRidoW+fIHvU4EFuiM7nho+xQDqaOncF4M9k= X-Google-Smtp-Source: AGHT+IEyceq4+kBUl0vO2/4YDku+bQP679QYDE62kFXkhp1YXBMMKDj36n4XaVkoTSJsA2PLbkl37+Rxa/psvo8zVdQ= X-Received: by 2002:a05:6512:3c86:b0:507:a40e:d8bf with SMTP id h6-20020a0565123c8600b00507a40ed8bfmr10617359lfv.7.1701103298273; Mon, 27 Nov 2023 08:41:38 -0800 (PST) In-Reply-To: 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:313285 Archived-At: On Mon, Nov 27, 2023 at 4:23=E2=80=AFPM Dmitry Gutov wro= te: > > On 27/11/2023 18:04, Jo=C3=A3o T=C3=A1vora wrote: > > On Mon, Nov 27, 2023 at 3:45=E2=80=AFPM Dmitry Gutov = wrote: > > > >> 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-specializati= ons > > 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-provi= ded > > 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. > > We in the end we'll have dozens of similarly-named commands with the > same implementation, right? Some of them in the core, others in > third-party addons. What same implementation?? They only common part is is literally just the string "xref-define-finder", the opening and the closing parenthesis. Then comes the backend specifics. A JSONRPC-based transport with a specifi= c protocol, an HTTP transport with another protocol, a ask the oracle of Delp= hos protocol, etc. Realistically, most people will be using Eglot anyway, so the existing eglot-find-* commands are what they're going to see and use. > > But you could put the existing xref-find-definition and xref-find-refer= ences > > commands in it. Even the "find-all" could be there. > > That... doesn't sound very convincing, TBH. That's obvious. It's clear to me that you are already convinced of whatever you want and all this discussion leads nowhere. So do what you want. If I like it, Eglot will use it. Else I will do my own commands in eglot.el. It'd be nice to reuse as much of Emacs as possible, but when it's not suitable (like many parts) or takes years to bikeshed to an agreement, I don't have to. I think I've given this discussion enough energy argument, etc. You're familiar with all the technical limitations of Eglot, etc. So, to summarize, I will branch from `feature/xref-find-extra` in that well-known point, polish some things there to a mergeable point. If you come around and want to merge what is basically your own patch of a month ago, great! Jo=C3=A3o