From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Sat, 11 Nov 2023 07:38:37 -0500 Message-ID: <87r0kw8nxu.fsf@catern.com> References: <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: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36606"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:ggS/H29xHKUWoL2jbzrBF19P6jM= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 11 14:40:18 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 1r1oDh-0009G9-Kf for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 14:40:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1oDG-0001JS-PN; Sat, 11 Nov 2023 08:39:50 -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 1r1nGL-00006E-On for emacs-devel@gnu.org; Sat, 11 Nov 2023 07:38:57 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1nGG-0004lh-Lu for emacs-devel@gnu.org; Sat, 11 Nov 2023 07:38:56 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r1nGE-0006nM-Qa for emacs-devel@gnu.org; Sat, 11 Nov 2023 13:38:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 11 Nov 2023 08:39:49 -0500 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:312562 Archived-At: João Távora writes: > On Fri, Nov 10, 2023 at 5:36 PM Spencer Baugh wrote: >> 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. Oh, this is very convincing. In fact, I am fully convinced. Major modes should define their own commands for the functionality supported by that language. So e.g. c-ts-mode could define c-find-signature, which has a clear meaning for C. And likewise for refactorings which only make sense in a given language. And we could reserve single-character bindings under M-' (or something) for the major mode. For example: (keymap-set emacs-lisp-mode-map "M-' g" emacs-lisp-find-generic) (keymap-set c-mode-map "M-' s" c-find-signature) Reliably using bindings under M-' even if those bindings point to mode-specific commands is enough consistency for me. Using literally the same command in each major-mode is not necessary. That's everything that I wanted from adding xref-find-declaration and so on in the core, so I agree, actually, we don't need standard kinds in the core or anything, as long as we actually do something to encourage common bindings. (And maybe we could use M-' M-r as a prefix for mode-specific refactoring commands. Perhaps if we use this M-' prefix it can be the start of encouraging more binding consistency between programming language major modes, which I find is something sadly lacking. Maybe at first there could be a customization which changes M-', and we could hope to change it by default in a subsequent release.)