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: Thu, 9 Nov 2023 20:44:37 +0000 Message-ID: References: <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> <953056ea-9cfb-34ad-6515-9036633dfdbb@yandex.ru> <2d964697-2b4e-64c7-2f16-aae87e57def4@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="11616"; 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 21:46:17 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 1r1Bur-0002qu-8M for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Nov 2023 21:46:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1Btn-0000N8-U9; Thu, 09 Nov 2023 15:45:11 -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 1r1Btf-0000Kk-VQ for emacs-devel@gnu.org; Thu, 09 Nov 2023 15:45:05 -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 1r1Btc-00047n-IX for emacs-devel@gnu.org; Thu, 09 Nov 2023 15:45:03 -0500 Original-Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-507a62d4788so1780358e87.0 for ; Thu, 09 Nov 2023 12:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699562689; x=1700167489; 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=uqeDiWmDwjA9epJAXrzGsyUj/Cm3HAYKRPCgwI6yLiQ=; b=SUB47X4ImNjdYa5NDADEEwTY7P29A1IiSkVWzvFHUAemmQy0rKT4TPDmTzDupm9pgX /Zi4KuilkmDYX+Tx0/RuzSVMpzlo7fMWCxJLChJTwNLXkgq3dvO/nO5QSXxUKag8nNec GmCXGSQ8HOwq3HrDyLCnNk/iDXSGcx2XWdYwnvU4XerRfBj6U5fcCVuhmlxC9SxxyokY GE/6DEoUiNVw2apZfINfVTOtCxw1YtsgvGAEDE5p541iIhrvyXaH2ixeZKdbF4DcS/RR dRWozPo5RPZ9ulsIsAPbFON3B5vx42lEQf0GMJC92cjUNjbTXnmtaXAZke40rus2s5wp Fnqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699562689; x=1700167489; 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=uqeDiWmDwjA9epJAXrzGsyUj/Cm3HAYKRPCgwI6yLiQ=; b=VRSV/Y2Usb+MizkRci6+HtvFqHvHB8uoc7K5Ja3XbKiAuP2j1CCP/5Ioz8pN6KJJti zy4KesQXZwya5nakG5NyqBIiQnlCXD6FjpBUDomCGkEHswwrWbc9DDi1A+V3SrxdHVSm 5J447UxpvjtRGTEuboAUbY02GFulsGn5CTZ8tNGNMOvRatg/VR5DwTw1+7eodh8IZoBa zAzz2QUvrjB01M7FE7fbeSF4v3BE6yjT1//+5wAezsvOcOwJmYggUea0VkEwMxk+OaOE g3DgfRckcGBRUS9fsa66ZlYgOqVqwrdSho6DgKCpZB6mwpYQbRz0OVPvltzFgrJ0SSlI OaUw== X-Gm-Message-State: AOJu0YwbhDi2fJIzj2VPSVlujhYltobRd8kfgZ4zFkO1xbTjecJFNHhH CaZmF7+1rqOv9i8FlCcuTZ+ijRkMCVpZtfZHpZMoznyC+VYtVg== X-Google-Smtp-Source: AGHT+IEuplWCmYMIqCcfHTtCIXbv8dNokb5FeR1oSDL5s1uImQcehRI3UkItM4nwlveXgHuW4c+uLnRUEc+JCt/izJU= X-Received: by 2002:a05:6512:61:b0:507:c7ae:32cc with SMTP id i1-20020a056512006100b00507c7ae32ccmr2100120lfo.41.1699562689324; Thu, 09 Nov 2023 12:44:49 -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:312443 Archived-At: On Thu, Nov 9, 2023 at 7:23=E2=80=AFPM Spencer Baugh wrote: > > Jo=C3=A3o T=C3=A1vora writes: > > On Wed, Nov 8, 2023 at 11:34=E2=80=AFPM Dmitry Gutov = wrote: > >> > But neither was available at the time, so I did those commands and t= hey won't > >> > be obsoleted any time soon. > >> > >> Reasons being..? > > > > That we can't come up with alternatives to exactly that interface, > > obviously. When you do, I'll obsolete them. But do you want to hardco= de > > things like LSP "typeDefinition" and Sly's "who-macroexpands" somewhere > > in xref.el? How would that work? > > Right, so if we have kinds defined in the core for "declaration", > "implementation", and "type-definition" (maybe not with those exact > names), then we can have xref-find-declaration, > xref-find-implementation, and xref-find-type-definition (again maybe not > with those exact names), and just do > > (define-obsolete-function-alias 'eglot-find-declaration 'xref-find-declar= ation) > (define-obsolete-function-alias 'eglot-find-implementation 'xref-find-imp= lementation) > (define-obsolete-function-alias 'eglot-find-typeDefinition 'xref-find-typ= e-definition) > > Is that possible? For Dmitry to answer, but I think we had established that is a slippery slope. Many languages have different exotic concepts, like Lisp and macroexpansion, C++ template instantiations, or annotations. And conversely many other languages don't even have the distinction between the three you mention. And i'm only talking about the handful of languages I'm more of less familiar with, there are many many more. And many more can be invented with different types of manifestation, there's no shortage of imagination is language designer-land. Not to mention Xref can in theory be used to provide cross-referencing support in any type of work, not just programming. So I thought, that about 6 months ago we had established that "definition" and "reference" are two relatively safe concept to keep in xref.el, but other concepts should not be in there, because this doesn't scale well and could imposes awkward structure and hacks into an unknown number of backends. Has everyone changed their mind? What exactly bothers you about eglot-find-declaration/implementation/typeDefinition? In LSP-land these concepts _do_ make sense, because the LSP standard prescribes what servers should do with them. What practical problem are you trying to solve? Jo=C3=A3o