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, 05 Mar 2023 23:00:11 +0000 Message-ID: <875ybe4xdw.fsf@gmail.com> References: <1587ddb6-f631-0890-965a-c7acb5729fa6@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="27247"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) 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 23:59:00 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 1pYxJk-0006vR-8V for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Mar 2023 23:59:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pYxJ9-0006XT-HH; Sun, 05 Mar 2023 17:58:23 -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 1pYxJ8-0006XE-B9 for emacs-devel@gnu.org; Sun, 05 Mar 2023 17:58:22 -0500 Original-Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pYxJ5-00019P-4F for emacs-devel@gnu.org; Sun, 05 Mar 2023 17:58:20 -0500 Original-Received: by mail-wr1-x432.google.com with SMTP id j2so7068915wrh.9 for ; Sun, 05 Mar 2023 14:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678057096; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9fhjqjORCAx0ExapI/7UIWTAdUqdVs41UhnMBjlfhFw=; b=gdwFqsD8zmLQnq20JRKVqqKj1fhIGfGryDcGSgF48xNFCOmR0yivBsoLI3vCo+kfUu fbMQh/CFH7Ch8O/CYBD7XE21C2HpgP1vwyNmXGMCIqz7QMI43/ngg+S2giJZIWPbuDMR 6iEXHqC2Zkqrt6D7CsnB+AgGUnuTpvo2GI2dSrDglAd2cOw6x6s2GWdxiCvBtIborwdq 9DL/eLSwLDpipoAv69jv1LOnxn33XjVGEHQDdO1eu89jWiOkRacu/NOaKL4L3fNgPScM DoysHh5glkI8cObtytru2+RIIdGAI1xaLdycTDoyKLtiYtbTTmSogmxHrL0BzL/fX82v VyeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678057096; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=9fhjqjORCAx0ExapI/7UIWTAdUqdVs41UhnMBjlfhFw=; b=WdbaidJzhjTLhaWFa1FHWrtcuiKQWSh7m2E8dyqXxy+X4frD6SSNnYPOuAzgGpqX2s LPxKsCS+Id1VGUoYtko9OJP8rkLa/cxQx3EqPwuVDhUVzO7bw9KPoNuksNZoPeAXS8CG 4DhVIgRLBt033P3nUhLng3uMovImVpHYVZsa3FNZxmCk74ZbLSAoNip3JT3E0Y93QtN4 kmPeYOnJiPz8NevxWoTUcTvjyi4xRlMt2UZzuyfRNzxc/Ga/70diaoXoW6o5sVNZGzcz MBUYzE2a9lsvXSSJOtSlgdFwJgDTzLCOgyXy35QaTImRu+8rODDV42tCoyDabW7azIuI 8FsA== X-Gm-Message-State: AO0yUKU8rwjxpopCPg4+gBLKDHMjOzMHA3MyeT8xdhfXzZkz4gacg/G6 xRC90eqn9ve0d3XfyyV0nAu6bSkhJdw= X-Google-Smtp-Source: AK7set/pRJVDBqM8REGlitsEnmEa+GPfaL55MW83oKmm3p7xQEsMw4ujQibGD3sPjMJdfCRJ7nWqpA== X-Received: by 2002:a5d:6284:0:b0:2cb:d8f1:1d2f with SMTP id k4-20020a5d6284000000b002cbd8f11d2fmr6003809wru.17.1678057096578; Sun, 05 Mar 2023 14:58:16 -0800 (PST) Original-Received: from krug ([87.196.72.142]) by smtp.gmail.com with ESMTPSA id b12-20020adff24c000000b002c556a4f1casm8215833wrp.42.2023.03.05.14.58.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Mar 2023 14:58:16 -0800 (PST) In-Reply-To: <1587ddb6-f631-0890-965a-c7acb5729fa6@yandex.ru> (Dmitry Gutov's message of "Mon, 6 Mar 2023 00:08:41 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::432; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x432.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 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:304007 Archived-At: Dmitry Gutov writes: >> 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. Lisp macros are great for cutting down repetition. If all we want to say is "this mode for language foo supports finding xref finding of 'declaration' it could even be as simple as (xref-define-find-command :declaration foo-mode-map) at the top-level of foo-mode.el. An Eglot xref backend would pick up on this ':declaration and hook it up to LSP's 'textDocument/declaration' (if it makes sense). Other xref backends would do whatever. A default binding in foo-mode-map could be chosen by xref.el, answering your other objection. Finding these lines in major-modes be as common as say, easy-menu-define. Additionally, if the Foo language additionally has "interfaces", and "macros" and "gremlins" and the FooLS server supports those (via LSP extensions which are somewhat common), then foo-mode.el can use some similar xref.el macro for definiting specific commands for those. Their implementation would use jsonrpc-request for the custom 'x/foo-find-gremlins' JSONRPC request, eglot-current-server for finding the server, and xref-make-match for making the objects. >> 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. "This command is not supported" errors or commands with same bindings that do something else are perfectly possible and pretty common in Emacs. But they are not the best examples of UI consistency. > 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 doesn't know about languages, nor should it. It's also not "natural" for Eglot to provide commands and UI: its job is to hook up Emacs' facilities with LSP interfaces. The first bullet in eglot.el's commentary explains this. Anyway, if you have like your approach, don't mind me. I'm just suggesting alternatives in hopes they can be useful, not standing in your way. If you want add things to Eglot's xref backend, that's fine in principle, but it's better coordinate first. Jo=C3=A3o