From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Mon, 6 Mar 2023 00:08:41 +0200 Message-ID: <1587ddb6-f631-0890-965a-c7acb5729fa6@yandex.ru> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40927"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Cc: Helmut Eller , emacs-devel To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 05 23:09:54 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 1pYwYD-000AWU-RF for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Mar 2023 23:09:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pYwXB-0003ZP-PS; Sun, 05 Mar 2023 17:08:49 -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 1pYwX9-0003ZG-Kx for emacs-devel@gnu.org; Sun, 05 Mar 2023 17:08:47 -0500 Original-Received: from mail-wm1-x32b.google.com ([2a00:1450: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 1pYwX7-00021V-O2 for emacs-devel@gnu.org; Sun, 05 Mar 2023 17:08:47 -0500 Original-Received: by mail-wm1-x32b.google.com with SMTP id k37so4615798wms.0 for ; Sun, 05 Mar 2023 14:08:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678054124; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=wJoMrGsFuLnRpOX8p1svGrOthuHBGY2iWrayDxnesQ0=; b=oiGXpaBzDOrwEaExRMJQx+ufT1Be8BCm3ilwaYik643loNA9c2dImTvMG9MfQhgLcH 7qv61jSPYQWmUweeCescA8aLb203gUmQpwM3nbE4r3p8LybJ5qs7chLOz8CXY8XGM9Sd LOwcF1reNXcx1U9o5zGMtDGEOR0+g6vgYJy4kYO52jh/zuAIh8C1XAlHzVG07uSPf+rd i7D37l1HUHEVTdIavgEgvvvH1mk51c8yfIiILhfOvMonMPpMoawihRuAK8Qz57EHBHR6 QsGXZ0XWOQ4NIFAl51IUwlJgslA27NY7sbPU/azzchPEBBU4tuz0ZuA+n/wdAFj/Bqo4 zaMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678054124; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wJoMrGsFuLnRpOX8p1svGrOthuHBGY2iWrayDxnesQ0=; b=oNf9fD+dCPYIbIanOyD6uRFvure8/ykg5uiheouKxOdiLvYrYBbQETqUeUpyjFLd37 mv/u46FLUbI71duQMbZECkK5IpL5r18MsJFA70ATD6ZAiLC1F0gpGpjocNqTLzimnV5I ESOhHsFvJ1QPFz7JolhpuIbLqEBzREwneZryChlOuCIpJQFWfSNloiDTdD5MeXOdvVAX fLVzMJvmqAOL27Pns2ttHJKvhV1kh7IgrVHcXyrLX2WlP65GOosWohH55fiC6wXnSg1U 9048Z2sVNaDMuQbysgyl7OyIAFvWmDtjvCdm0H1O7/DnPEiyavsaX/lxTVSAhMZRI7jB I6HA== X-Gm-Message-State: AO0yUKXm7Gogm0SPRnxqNMng41Lp92kNcjWdR8dtRV1agzXQvA3QM9Ij W98RWQsYIEUUoPCFSr9Ihvs= X-Google-Smtp-Source: AK7set/25JH78nsSnn61PbEwzDUZBWKUI6A0EtOSNIapC8x5PQl5S+CZg6qm31lIhRrc1OaV9q59Ng== X-Received: by 2002:a05:600c:35d5:b0:3eb:3945:d3fd with SMTP id r21-20020a05600c35d500b003eb3945d3fdmr7522338wmq.14.1678054123779; Sun, 05 Mar 2023 14:08:43 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id v28-20020a5d591c000000b002c6e8af1037sm8185223wrd.104.2023.03.05.14.08.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Mar 2023 14:08:43 -0800 (PST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::32b; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32b.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:304000 Archived-At: On 05/03/2023 23:48, João Távora wrote: > 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 > 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. Right. So we'll have a dozen commands with the same two-line definition, different names, but the same binding. > 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? Having a common binding and a common xref backend method to dispatch to simplifies things. The major modes which don't have the notion of 'declaration' will have options: do nothing (and simply have the command return an error), or rebind the keys to a different command. Note that whether the command works will also depend on the current Xref backend. etags will likely support declarations in a smaller set of languages than LSP clients. And yet some specialized packages can cover some of the remaining languages that LSP doesn't reach. A major mode author won't necessarily be able to tell in advance whether an Xref backend will exist that would cover their language with this particular feature. > > 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. If we don't want to extend xref.el with such commands, packages like Eglot seem like the natural alternative, though. Because they can know which commands the LSP protocol can support. Eglot could even query for that support at runtime for a particular language, I think. > 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. declarations/implementations are definitely less universal than the first two. But I don't see how they will hurt: if we decide to extend the list, the main difficulty will just be choosing the bindings, I think.