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:17:43 +0000 Message-ID: References: <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> <87il697r5g.fsf@catern.com> 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="35227"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Spencer Baugh , emacs-devel@gnu.org To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 11 12:15:40 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 1r1lxk-0008v9-QL for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 12:15:40 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1lx2-0004f8-ET; Sat, 11 Nov 2023 06:14: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 1r1lx0-0004ec-7h for emacs-devel@gnu.org; Sat, 11 Nov 2023 06:14:54 -0500 Original-Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r1lwy-0002JJ-Es for emacs-devel@gnu.org; Sat, 11 Nov 2023 06:14:54 -0500 Original-Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-5098e423ba2so3959877e87.2 for ; Sat, 11 Nov 2023 03:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699701290; x=1700306090; 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=filKCMZGJUqjkIaMBo4NDqyjs/P0xjlDz0WwQuo2WE8=; b=Iz5vzmDzMbEzAdkKo+54DorEL3on7h6p9hH3RHJnqbpiSs/sMQcL3TGPoeb9tVwox5 QfHbiHUWTNB9xQoX/jSfypdomjiNEAb6QQkFHg74jNwm+9j51vUNgYWq5GPq6ah7gesb CZmxAYEnu/7hGxVQd4CQXgvop4EX5uL8xxdMoHOz3zccKXwWEubJgDLG1yZ8WTWIYB6c D9KsMoLcrBHdQtd3lnTdSzfkA806VRwk337mLr0yJtr5p7PN6H3FAepQKKH+zg7OucBB Smcep+GIDHhF2GPUrRLTnBTCkPVmPBOkbqCYEzzzQLRBzQITNiLzApBRCM/0irrKi67L sHXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699701290; x=1700306090; 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=filKCMZGJUqjkIaMBo4NDqyjs/P0xjlDz0WwQuo2WE8=; b=WNHZ+47zUVbWBQ87O0tONDeVN0gNdrFH6lMomxm2KGJ3afDh8QnOKuFfm9OcNhu9NW gSCZ+CucCmpvxv9S+zLdvCTWo0zKkUjtr5MMNhMbKaAcoMw8ALXVq83grVKiD92RMvnp 35bUjZz71VJfARS/38miK1kfmaecb+9LSt8DstI/OTMGAuJbwERfaO8thguiAPwqG6v6 YkZGzIqpXptsauowHrsi017bHyimx64Cj4TkjaEJm6jaoa2Tiis0jkKUuMCp2MWhkBod hGCEHGSAJIJCFpatCtPM/QYkzjhUh/PqO2qy4BfvvivBkYe5f8g1BvATtqGEPAeMwRci Xbaw== X-Gm-Message-State: AOJu0Yw9OX7dP826WR2Me807tbLj93QIxhvDsnEevdahw7ue9c6p2L4K Sjl8M+EEwk4Z16L0W/GrsMp+bQaN4+ffAxeuQ+M= X-Google-Smtp-Source: AGHT+IHCjDIJrGYlqc3nsl5d/VDtXfoF6yxsnp14edJJ+NyrS9wp6U8RO/lujRcqaLJsCUeIDOmhMVM54kW0psHhDBE= X-Received: by 2002:a05:6512:48cc:b0:50a:2710:d206 with SMTP id er12-20020a05651248cc00b0050a2710d206mr1017364lfb.66.1699701289597; Sat, 11 Nov 2023 03:14:49 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::131; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x131.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:312540 Archived-At: On Fri, Nov 10, 2023 at 5:36=E2=80=AFPM Spencer Baugh wrote: > > Jo=C3=A3o T=C3=A1vora writes: > > On Fri, Nov 10, 2023 at 12:15=E2=80=AFPM Spencer Baugh wrote: > >> > When I get around to finishing refactor.el which will inherit most o= f > >> > Eglot's UI for doing refactorings, I don't plan to burn the concepts= of > >> > "organizeImports" and "quickfix" into it. They are LSP things. > >> > >> Sure, that sounds good. But do you hope to eventually add a standard > >> keybinding for accessing refactor.el? I hope so. > > > > Sure, for refactor-code-actions, which will work much like xref-find-ex= tras, > > aka xref-find-by-kind (or maybe it should be named only xref-find, or > > why not only > > xref). > > > > But there won't be a command refactor-quickfix or refactor-organizeImpo= rts > > because not all potential refactor.el backends support those LSP concep= ts. > > > > It's exactly the same here. > > And refactor-code-actions will behave like the current > eglot-code-actions, and prompt for code actions iff there are multiple > possible actions that can be taken? I know you prefer that workflow > personally, but some people like keybindings to do common tasks > directly. Yes, and there will be eglot-* commands for those common LSP-specific tasks yet, just like there are these commands today. eglot-code-action-quickfix eglot-code-action-organize-imports etc. The only difference is not user visibile and is that they are to be defined internally with a macro from refactor.el. > For example, do you expect to support symbol renaming in refactor.el? > That if anything seems like something which deserves its own binding. Yes, it will have its own command, and you can discuss with the bindings people to bind it to some key, I won't oppose it. refactor-rename is analogous xref-find-definition, it's a concept that we're very confident that we can provide in all refactoring backends, LSP or not. > That being said, maybe we could have mode-specific commands and bindings > for these things. So if something is supported in a language, a major > mode could make a binding for that. And then, just, we might encourage > using the same bindings in each mode that binds something. Aha! Yes, of course. That's the Emacs way. The advent of LSP sometimes makes us forget that LSP's tradeoffs are there because LSP doesn't have the concept of mode or any kind of programming language. That's why it is so stiff sometimes. But we do, we have a existing abstraction for dealing with languages, the major mode, a pretty flexible one. And we have a mature programming language. This is why indiscriminately borrowing stuff from LSP should really be frowned upon. Doesn't mean flat-out reject it, but scrutinized because tying ourselves down to LSP's inherent impotence is not something we want to do in an editor with our time-proven strengths. Instead, what we should do is lobby LSP to become more powerful. We won't get it to run Elisp, but a lot of things could be done to make Emacs/LSP integration even better. Just one example, be able to pass an arbitrary identifier to LSP's `textDocument/findFoo`. But I'm the first one who should be doing that, and I'm not, because I just don't have time, and the sad truth is that Emacs doesn't carry that much weight over there, unfortunately. So what we should do in the long IMO is take advantage of Emacs inherent advantage for language integrations so undeniably good that more users come use it and then we have more negotiating power. So yes, c++-ts-mode can and should define, and possibly bind, all those xref.el and refactor.el things that make sense for C++. And if binding consistency is a goal, then major mode authors should coordinate. And we can even have Elisp constructs that help this coordination and make uncoordination difficult. - Putting any talk about common xref APIs aside... Just to be clear, my > understanding is that you have no problem with the idea of: > > - Teaching the elisp--xref-backend about separate 'cl-defgeneric and > 'cl-defmethods kinds, which return the obvious things Yes, no problem I think. Didn't think much about this, but bear in mind defgeneric forms can also have specific methods inside them. So there are at least to ways to put methods on generic function, not just cl-defmethod. Then macros come along. I'm not sure the Elisp backend is good enough to know that a macro expanding to cl-defmethod is a method-defining macro. SLIME and SLY can most definitely do it. But that's another problem. > - Adding commands elisp-find-cl-{defgeneric,defmethods} which use those > kinds (and which fall back to the regular definitions) No problem. But have a look at how SLY and SLIME do this. It's been tested for a very long time today there. I hope I can update SLY to use xref.el . I tried once many years ago, but failed, not really because of xref.el but because SLY's code is very convoluted.> > - Adding bindings in emacs-lisp-mode for calling those commands > I'd like to do that independent of whatever we end up with, so just > making sure you're not opposed to that, even though you might not be > interested in using it. No, not opposed at all to doing it. Whether I'm interested in using it it varies in time greatly. My personal workflow changes slowly over time, and of course it is influenced by the design decisions, it is not set in stone. But it does stick, to tell you the truth, I'm still using C-h f foo RET C-x o TAB RET to go to functions definitions when I don't have the symbol name under point. I know there's C-u M-. but I'm so used to that other workflow that I've used for 20 years, that I just can't let go. Plus I like that it makes me gloss over the docstring briefly. When programing C++ with Eglot, I do use C-u M-. of course. Jo=C3=A3o