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: Fri, 10 Nov 2023 12:36:18 -0500 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="39607"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Spencer Baugh , emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 11 07:22:19 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 1r1hNq-000A1U-8e for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 07:22:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1hMp-0000CC-KC; Sat, 11 Nov 2023 01:21:15 -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 1r1VQd-0005Ej-Cx for emacs-devel@gnu.org; Fri, 10 Nov 2023 12:36:23 -0500 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1VQZ-0004B9-VZ for emacs-devel@gnu.org; Fri, 10 Nov 2023 12:36:23 -0500 In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Fri, 10 Nov 2023 13:59:10 +0000") Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 11 Nov 2023 01:21:15 -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:312527 Archived-At: 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 of >> > 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-extr= as, > 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-organizeImports > because not all potential refactor.el backends support those LSP concepts. > > 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. For example, do you expect to support symbol renaming in refactor.el? That if anything seems like something which deserves its own binding. 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. >> I think that would be a really helpful new feature, apart from all the >> rest of this. >> >> If the term "declarations" and "implementations" are a problem, we could >> totally give them another name. >> >> How about "find-generic" and "find-methods"? Just literally copying >> what Elisp calls them. Then we can set aside all this worry about >> sharing terms with LSP. >> >> So let me restate my proposal in those terms: >> >> I'd like an xref-find-generic which in Elisp jumps to the cl-defgeneric, > > So what would xref-find-generic do in C++ code? It has no generics. > Most languages have no generics. Most programmers I know have never > even heard of "generics". "generic functions" even less so. Why do > you want to burden these non-Lisp people with this new concept > from Common Lisp that they'll have to map to their own favourite > language they want to do their work on? And no, never will "generic" > map clearly to the fundamental C/C++ concept of a declaration, for > example. Not to mention Java has templates called "generics". > And C++ has templates called templates. Completely different concepts. > > So IMO this is just a very bad idea, I'm afraid. > > But I think we have made both our positions clear. I understand what > you want to do and I am completely against it, but this is not just > up for me to decide. The only thing that is, is that if I like the > new interfaces in xref.el I will implement them in eglot.el. The > UI that xref.el provides I can't control. Of course I recommend > keeping at least the current UI of xref-find-extra, not least because > it's something that has actually been implemented and I have > spent time integrating. And I also like your idea of KIND=3Dnil to > make it show a sectioned listing using whatever kinds the backend > declares as section headings. OK, fair enough, and I can see your point. I think we're both clear. 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 - Adding commands elisp-find-cl-{defgeneric,defmethods} which use those kinds (and which fall back to the regular definitions) - 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.