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 00:50:43 +0000 Message-ID: References: <4639d7ca-2109-864c-33c0-38e65f26f262@yandex.ru> <835ybb3txt.fsf@gnu.org> <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="6679"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eshel Yaron , Spencer Baugh , Eli Zaretskii , stephen_leake@stephe-leake.org, john@yates-sheets.org, rms@gnu.org, fgunbin@fastmail.fm, casouri@gmail.com, emacs-devel@gnu.org, azeng@janestreet.com To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 09 01:52:08 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 1r0tHD-0001Uv-Qq for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Nov 2023 01:52:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0tGH-0006mp-Gx; Wed, 08 Nov 2023 19:51:09 -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 1r0tGE-0006mg-Vo for emacs-devel@gnu.org; Wed, 08 Nov 2023 19:51:07 -0500 Original-Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r0tG8-0006x2-LW; Wed, 08 Nov 2023 19:51:06 -0500 Original-Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-507cee17b00so350007e87.2; Wed, 08 Nov 2023 16:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699491057; x=1700095857; 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=UC4jImGj0h8vbP9ieKt/y1GjP4TKT/0TACAafKJF5SA=; b=novta303uWWVsOmbowj3kw64hAdBYgPZry5Y5wV22A92ispWf+4QVr+eWwW6PU7V7q 66P2J1zxBTMoasNiZ8IXK8YlRg7uNOswpMWQFCMtt7brOBuaZ/kl1haJZuWF/pk8iSfv pk1biNZpYrPB9KR5lJ4E7PN8APeK9lB8URdpKKKCcUKkdEJQOTngxOx2QN3AemdqTybS C/wCBlY6XhJODg0yDbkXySPwYlpGezfzPtQRHMMSzNxM1KX+KPrcmqVCLgSPVIOBmRCr nEd2osWXv1AuXfawlz4ycoeNsRvbzdK+PWmEanH++0ZvgNwrtKBSJP/A2anxxBEvY7Ct DXVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699491057; x=1700095857; 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=UC4jImGj0h8vbP9ieKt/y1GjP4TKT/0TACAafKJF5SA=; b=w2ivHNF1XfSk+4JHKKz7F/gU/HhJMqLokh509n9RN6PcZjVPhPxM+NYxTsOTHTAKNI q7LfnKDJrWMuoZ5U0D2x9eSoiwZSpZ5KFFkhcgzzonK+xOTg8DeXQ3UBw7TXhcl55svc eHtWkQzaaFGUs4N3r0UEtbFQzE9bw9pj2hEvSOw6z181t1rLY/ssPNARpK09c9Z+HNIT +kJpLI1OrvvfR6aFT70SrvsS471feHW2KicSVxDoLKOgp5QsxAIurr/UOijRZB1Qcr2W VVUlJ6lbIGnZByNdCYLTvFxL7LA5B0e5iOIQtiwvJshQyfWV/b0N1YEWD2Rkrapnj//e ba3A== X-Gm-Message-State: AOJu0YyVm9pTtUG+Li7BB/Je8CjYTD3JNVj4kth6vlwsNEVa9qAvlUCD IViZkZUteQ5utki/7vF5y+OM/kevAhLUnidyxjs= X-Google-Smtp-Source: AGHT+IEx8WoxlTcYvHpUYaex6dmFGKczQxA3A+x5nZmuGjML9Vm6VOUHCCZ4EUkbtf3MjrlHA67Xp3qFur33kx5Ieuc= X-Received: by 2002:ac2:5586:0:b0:509:497c:9623 with SMTP id v6-20020ac25586000000b00509497c9623mr115120lfg.37.1699491056396; Wed, 08 Nov 2023 16:50:56 -0800 (PST) In-Reply-To: <2d964697-2b4e-64c7-2f16-aae87e57def4@yandex.ru> Received-SPF: pass client-ip=2a00:1450:4864:20::132; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x132.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:312373 Archived-At: On Wed, Nov 8, 2023 at 11:34=E2=80=AFPM Dmitry Gutov wro= te: > >> For the purpose of such design discussion, simply using Eglot's comman= ds > >> is not a good choice. > > > > I don't get this talk of obsoletion. I don't want to obsolete anything= . > > The Eglot commands are there because they fulfill a need that > > generic xref.el commands will never be able to fulfill. > > If Eglot keeps its commands (which I don't mind that much), then any > comparable package should also be allowed and even encouraged to define > its own commands. And we should document that somewhere, too. Not necessarily encouraged OR discouraged. Just possible. Why complicate things? > But that design ends up far from the original "Eglot shouldn't do this" > sentiment that I have read before. It might be useful to check this code in eglot.el. Code actions are very similar to what we have with definition finding. Look: (eglot--code-action eglot-code-action-organize-imports "source.organizeImports") (eglot--code-action eglot-code-action-extract "refactor.extract") (eglot--code-action eglot-code-action-inline "refactor.inline") (eglot--code-action eglot-code-action-rewrite "refactor.rewrite") (eglot--code-action eglot-code-action-quickfix "quickfix") This is exactly the same, with the exception that refactor.el doesn't yet exist (working on it) and 'eglot--code-action' is thus not refactor-define-code-action Now, I don't use those commands, I use eglot-code-actions directly or Flymake clicky diagnostics, but users requested those commands, so I put them in eglot.el. They could be in some eglot-ui.el. But it doesn't mean eglot-code-action (soon to be refactor-code-action and which, like xref-find-extras, uses completing-read) is any less useful or incompatible with the commands created by these one-liners. To make myself clear: when I say I don't like to add UI to eglot.el, it means I don't like to do it when a clean abstraction for a similar concept can be cleanly implemented, or even already exists, elsewhere for other non-LSP things. But sometimes those two conditions simply aren't true and can't easily be made true, like here. So instead of endless soul-searching about what I would like a zillion language servers and an Microsoft-owoned VScodish couldnt-care-less-for-Emacs protocol to look like, I create the simplest possible Eglot UI and reuse as much code of non-Eglot UI libraries as possible. > And also, Eglot keeping its commands seems incompatible with (or at > least counter to) the approach where is an existing set of "extra" > commands that is bound to some prefix map (e.g. one assigned to M-'). > Because if there are many different commands called *-find-declarations, > it seems difficult to put them all on the same key. Eglot doesn't put any commands in any keymap. It just offers them. > > But neither was available at the time, so I did those commands and they= 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 hardcode things like LSP "typeDefinition" and Sly's "who-macroexpands" somewhere in xref.el? How would that work? > > The base of the current design, the xref-backend-extra-defs and > > xref-backend-extra-kinds, is more than sound enough. IMO could > > some micro-enhancements like better names and support for non-string > > kinds, but that's completely secondary. > > It's not secondary if people will start adapting their backends to it. If that's even a problem -- like there's going to be a plethora of backends doing that (how many third party xref backends are there?) -- strings-for-kinds can still be supported and you have obsolete alias. So yes, completely secondary. > E.g. the term "extra" seems more like a misnomer now, given that people > seem to want that command to include the kinds already present in > "definitions". And they might constitute the majority of those "kinds". Yeah, "extra" should be or "by-kind". Jo=C3=A3o