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: Sat, 11 Nov 2023 11:44:45 +0000 Message-ID: References: <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> <11b5a8be-b15c-f275-d84a-89c2a3a513f7@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="3903"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Spencer Baugh , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 11 12:42:46 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 1r1mNy-0000mj-En for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 12:42:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1mNA-0003P2-M2; Sat, 11 Nov 2023 06:41:56 -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 1r1mN9-0003Ol-A9 for emacs-devel@gnu.org; Sat, 11 Nov 2023 06:41:55 -0500 Original-Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r1mN7-0004mS-IT for emacs-devel@gnu.org; Sat, 11 Nov 2023 06:41:55 -0500 Original-Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-507ad511315so4141639e87.0 for ; Sat, 11 Nov 2023 03:41:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699702911; x=1700307711; 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=rk/awszbRLoY20r4ujl400T7xU3v7nQJIXHCqGPbfoU=; b=IXar3EkiUGzpHrdaInDbJRobnPnwINvv1xal+Mbu7LyagGwQztoKqJwLM0WdoGgGEr NyG7CEgMBKXZDkZCodSRvuDgLib8LIDKILikfx78GyV3K+2ZGF3/F32lJaCkwQq+8DU8 BAUQ7pG9vrBX1L36JtSpTybsfBTRnSvEf8OlpUy9lLbUu0fTiSJdVowZhBToDU6ZfETm aEVlDr5+r1SvhUefDNwCOM4FIqe1lyDSC8Uuqt9FUG+oDps3MIFHpPC47qr+IoI1x8+R NUQ8h40JTM0kJcN4rvwQ+X6iFP3BI2pdCZqsGuf/g8FcrK0yaDj9ktj7jfi/QYtQeGdw ktow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699702911; x=1700307711; 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=rk/awszbRLoY20r4ujl400T7xU3v7nQJIXHCqGPbfoU=; b=Pa6B9T/4bBCrnHmRBYFhNMYFkK6tPS5F+CyPRx5rc56hHF8VFcPE/LfozyV/uT01b9 wE5d/Q44onqLSq7o5RLFTNPM3fRGrcIkLFiNBxMerTVjahXc1PpJl1N4JJ5vQYk9Inli hL86szpYmoo8r1jSjDFcF8Ugkeb/h62u1IuZ5lVb24eimX3D/gpbSlGwKfVkupg5Hxwi 8HCYYuSoeSGeesqBpG6k/I/fORsIrZUzHoy86QXsBgQPsAXRtR1LIVhLoLPctfR4fT6b DbTslUANLf/lkasdMa3GdaYnH6+j0TMtBQrjhqeV/yd9p/3J7dh7HluVDkxROc4L+9bZ sFBQ== X-Gm-Message-State: AOJu0YxZNqcptuwr8qmB/xiOrmQrngahSNpDC5yilxPEF35a88vx9LX6 7Zp1HZNKLFj4ZWCX7h5nI6ZFYC3YWpyCD036D2I= X-Google-Smtp-Source: AGHT+IF0fnaDScO6lq4P3i0ZfxUfGoEiXFbdmdjbnf25SiK/v/utxiADPoZcURSF6zo4PQg6wvdQObgD8fl/hMq4hcE= X-Received: by 2002:a05:6512:2f1:b0:507:b935:9f5f with SMTP id m17-20020a05651202f100b00507b9359f5fmr1000422lfq.24.1699702911242; Sat, 11 Nov 2023 03:41:51 -0800 (PST) In-Reply-To: <11b5a8be-b15c-f275-d84a-89c2a3a513f7@gutov.dev> Received-SPF: pass client-ip=2a00:1450:4864:20::12b; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x12b.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:312543 Archived-At: On Sat, Nov 11, 2023 at 12:58=E2=80=AFAM Dmitry Gutov wr= ote: > > On 09/11/2023 22:44, Jo=C3=A3o T=C3=A1vora wrote: > > 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? > > My impression is that the first feedback from our patches actually made > people excited about things that _weren't_ included in the > previously-discussed plan, so it seems like a good idea to re-evaluate > it. Though not necessarily redo it all. > > Though I guess this particular mailing list might be biased in favor of > particular type of users (keyboard-driven, faster interaction as a > priority). yeah, the sample size is so small that's it's more than certainly biased. > > 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. > > I think we've actually discovered that these kind of make sense for > Elisp too. They might not match the current implementation, but > conceptually, in some future, they might. Yeah, they "kind of" make sense, but not very well and IMHO that's not a detail, but a big red flag. It's clear, and I understand your point, that if we were to squint to contort to them we could have xref provide a consistent "works everywhere" UI. But as Spencer noted it would be "works _mostly_ everywhere". And, as I noted, the contortion might lead us up awkward alley, such as finding a list mixing `declare-function` and `declare (compiler-macro` in the bag of xref-find-declarations. And Spencer even wanted to put cl-defgeneric in that bag, which I can fully understand, as cl-defgeneric can also be viewed as a declaration. But its a completely different concept from those two. And then SLY would probably make the bag slightly different yet. And every time you use Eglot to connect to a different LSP language server you see a different bag of concepts yet again (but that's not our fault). So that sought-for consistency vanishes quickly. So, I think that if what we want is ultimately to promote UI consistency for programmers of different languages, we can come up with xref.el helpers for major modes (and eglot.el) to help achieve coordinate "a degree of consistency", as Spencer wishes. But we have to note that full consistency is an utopia only fixed by fixing the root problem, which is that languages are different, and I think we don't want to "fix" that. Jo=C3=A3o