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: Sun, 5 Mar 2023 21:48:40 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f7469605f62e24e1" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25837"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Helmut Eller , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 05 22:49:42 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 1pYwEg-0006Wk-3m for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Mar 2023 22:49:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pYwDz-0006NX-Pa; Sun, 05 Mar 2023 16:48:59 -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 1pYwDw-0006NF-BD for emacs-devel@gnu.org; Sun, 05 Mar 2023 16:48:56 -0500 Original-Received: from mail-ot1-x32b.google.com ([2607:f8b0:4864:20::32b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pYwDu-0007Sg-0U for emacs-devel@gnu.org; Sun, 05 Mar 2023 16:48:55 -0500 Original-Received: by mail-ot1-x32b.google.com with SMTP id a4-20020a056830008400b0069432af1380so4347513oto.13 for ; Sun, 05 Mar 2023 13:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678052932; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=F6K/5ymTydYxYqcCaMbzw30ovtU7UOeN17AyDN6Pf20=; b=ddvPnD3XPj5oyDxgRLefH8vcLf/t21WJMzYsKv2C4+6hLXh9PNNOdkZI/epe2DpXVw HYyeuh+bxboBRyj9y25NA8AD6VLj32CKzRD5VwyCedHlZZRE5DgVCPdU43AdhCZ6CJZp JIR3pBp3p+cpGUcr8GYn8uhgv3c4+yzCAd6X3lloYhnzSxSIx+hnsASUneEWwJawZuFL 12DirfKiQGrZKn9Ow8fvXgJ5PtgabPXJH/kB9jW3C0tLODAKdJ1deyrOZjpRK1bMFO3s 9qgtdDlFnggglMLZ0kgzEgXw6BJhvE/NvZ2yADnh4lQA38QPSBJl6X9ZVxvPebe0lmta nZGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678052932; h=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=F6K/5ymTydYxYqcCaMbzw30ovtU7UOeN17AyDN6Pf20=; b=FpfDByOofsv8bZZNnAvj+ERZRyj6y7J3mzYKm/16tjM/1/ZYxLH7lJRMJolr78uVhF UNfmws/gLAuiMsLvWrVHiCZWX1uuX3kCV0ULwzCWUI1kYx522qbUkaRKlUobihS7Jg3U C2lELmovoyA9g6b7zPrc7b83wBz0bmaBQE3YdfqfoIX+CNvix6GO3CkygZwmNDSSGUf4 /+mDbYt1YhHCoO1ZmMBn5Z0vPSuGZ/nPofB0dravRwMem/C/IUOg/72p3nIa8+WCqyjh nUNOPx+CVtvkBzT9CCro1t6PS7udX1l7DerwlyYUBZV/zvPwgWNbTIuGABLpXP8GQ/J6 zgIw== X-Gm-Message-State: AO0yUKUx/dOBw5f5nMUHaZBI5h6Tl71u0O/LJ6YOntu4BgNdPjp/7jQ1 QUZLea2/hLDlw+6M5aliX289zfKfcjoaXIzKG2o= X-Google-Smtp-Source: AK7set84j9RvsQPX3EclxYjKEjD+CnMnxJpzaQuJ9qfoKiLAMEdK/tQkv36cPntwuPUJ1z71f2qqAli0PU46V/kQ02s= X-Received: by 2002:a05:6830:2464:b0:688:cfcc:ddaf with SMTP id x36-20020a056830246400b00688cfccddafmr2592613otr.3.1678052932665; Sun, 05 Mar 2023 13:48:52 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::32b; envelope-from=joaotavora@gmail.com; helo=mail-ot1-x32b.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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:303998 Archived-At: --000000000000f7469605f62e24e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 5, 2023, 21:21 Dmitry Gutov wrote: > > Which modes? The ones where "declaration" is a thing. > > So we'll have a dozen different commands called 'xxx-find-declarations' > which will be implemented the same (?) way? Bound to the same key sequenc= e? > > If there a particular point to doing that? Do we expect other modes to > reuse the same binding to do something else? That will reduce UI > consistency, at the very least. > Implementation could be trivial, xref could even provide a command-defining macro. Consistency should be evaluated considering the two approaches. Is it more consistent to have an xref command that doesn't really make sense in a another dozen languages? > IOW xref should try to stay language-agnostic, but provide common > > framework for language-specific things like major modes to reach > > backends like Eglot or anything else > > Most programming languages have something that corresponds to the term > "declaration". > Not sure about that. But if one squints very hard, everything does indeed look like a nail to one's hammer. > Mind you the same point made for xref can be made about LSP, > > language-agnostic on paper, but many a language-specific concept poorly > > disguised in there. But I see no reason to copy that flaw. > > I don't mind the idea of extensibility (and packages like lsp-mode do > this already: IIRC they have commands called lsp-find-declarations and > lsp-find-implementations). > As commands, this would be bloat in Eglot. But Eglot can give access to these LSP interfaces. But insofar as languages do have shared syntactic concepts, I don't see > why we wouldn't want to include more common ones. > "Definition" and "references" are universal enough. "Declaration", "class" and others, not so much. But that's just my 2c. Jo=C3=A3o > --000000000000f7469605f62e24e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Mar 5, 2023, 21:21 Dmitry Gutov <dgutov@yandex.ru> wrote:
> Which modes? The ones where "declaration" is = a thing.

So we'll have a dozen different commands called 'xxx-find-declarati= ons'
which will be implemented the same (?) way? Bound to the same key sequence?=

If there a particular point to doing that? Do we expect other modes to
reuse the same binding to do something else? That will reduce UI
consistency, at the very least.

Implementation could be trivial, xref could = even provide a command-defining macro.

Consistency should be evaluated considering the two approach= es. Is it more consistent to have an xref command that doesn't really m= ake sense in a another dozen languages?

> IOW xref should try to stay language-agnostic, but provide common
> framework for language-specific things like major modes to reach
> backends like Eglot or anything else

Most programming languages have something that corresponds to the term
"declaration".

=
Not sure about that. But if one squints very hard, = everything does indeed look like a nail to one's hammer.

> Mind you the same point made for xref can be made about LSP,
> language-agnostic on paper, but many a language-specific concept poorl= y
> disguised in there. But I see no reason to copy that flaw.

I don't mind the idea of extensibility (and packages like lsp-mode do <= br> this already: IIRC they have commands called lsp-find-declarations and
lsp-find-implementations).
As commands, this would be bloat in Eglot. But Eg= lot can give access to these LSP interfaces.

But insofar as languages do have shared syntactic concepts, I don't see=
why we wouldn't want to include more common ones.

"Definition"= and "references" are universal enough. "Declaration", = "class" and others, not so much. But that's just my 2c.
=

Jo=C3=A3o
--000000000000f7469605f62e24e1--