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 07:02:19 -0500 Message-ID: <87il697r5g.fsf@catern.com> 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> 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="23334"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:VrR7hGoeNH2i13F0eZ+2Ik+1Ga4= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 10 13:15:41 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 1r1QQH-0005pM-1B for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Nov 2023 13:15:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1QPi-0005hF-Pj; Fri, 10 Nov 2023 07:15:06 -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 1r1QDf-00073X-P4 for emacs-devel@gnu.org; Fri, 10 Nov 2023 07:02:41 -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 1r1QDZ-0005RU-Rl for emacs-devel@gnu.org; Fri, 10 Nov 2023 07:02:37 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r1QDX-0009bz-N7 for emacs-devel@gnu.org; Fri, 10 Nov 2023 13:02:31 +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.25, 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: Fri, 10 Nov 2023 07:15:04 -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:312480 Archived-At: João Távora writes: > On Fri, Nov 10, 2023 at 6:23 AM Spencer Baugh wrote: > >> Well, Elisp for example has "declarations" and "implementations": >> cl-defgeneric and cl-defmethod. I'd like, in Elisp, a command which >> jumps to the cl-defgeneric, and another command which shows the >> cl-defmethods. This doesn't have anything to do with LSP, it's a >> feature purely for Elisp. >> >> I think we can support this without going down any slippery slopes. > > Really, what if the language du jour sometime in the future becomes > something like C++ again? Will you add 'type-instantiation, > 'type-specialization, 'partial-specialization, 'concept, and so on? > Or the C++ backend somehow manages to index the loci of memory > allocation to a given arena names at point. Will 'memory-allocations' > also appear in xref.el? > > These are all things a C++ backend may legitimately want to organize > much more than those 3 extra compartments, just like Lisp users > like to see who-macroexpands and who-calls. > > So yes, quite slippery. None of those make sense for Elisp, and "declarations" and "implementations" do make sense for Elisp (as I'll describe below). That's the difference. I think we should be somewhat "selfish", and let our design here be guided by "Things which make sense for Elisp, and also many other languages". Declarations and implementations, I think, are an instance of that. > LSP, the protocol has the same problem, and their 5 categories > (definitions, references, implementation, declaration, typeDefinition) > are awkward as heck and don't make any sense for many languages. > They're probably coming from large commercial languages such as Java > and C#, Typescript, etc not suprising given it's all a Microso$t > gig. But it's just poor design that I'd rather not have bleed into > Emacs xref.el. > > Emacs is older than LSP and my bet is that it will outlive LSP. Absolutely, of course, but just because LSP has "declarations" and "implementations" doesn't mean it's not good for Emacs. > Of course Dmitry is the person to convince here, not me. > >> We don't have to include the concepts in xref.el per-se. All I suggest >> is that instead of supporting 'eglot--xref-implementation as a kind, >> eglot should support 'implementation as a kind. > > By the the symbol you quoted is an internal implementation detail. > The fact that it can't be represented well under the current > patch is under discussion with Dmitry and it's super-easy to fix > whatever the outcome of that discussion is. IOW that prompt should > show "Implementation". > >> If a backend doesn't support 'implementation, that works fine with the >> current patch - the backend just errors when kind=implementation is >> passed to xref-find-extra. No awkward structure, no hacks. > > Oh, big awkward: > > 1. You lose the consistency you wanted so much. I can't > take my muscle memory from backend A to backend B. I'll just get > errors. Eh? You'll only get an error if backend B doesn't support one of the core kinds. I also get errors today if the backend doesn't support xref-find-references. That doesn't make M-? (xref-find-references) any less of a consistent UI for modes that support it. > 2. If backend C supports many more things other than implementation > typeDefinition, etc, they're either going to be awkwardly > organized into those drawers or available as backend-specific > commands you wanted to avoid in the first place. That is fine and exactly what I want. I see an area where a degree of consistency is possible, so I see no reason not to get that degree of consistency. "This other thing can't be consistent" doesn't make sense to me as an argument against making this somewhat consistent. > Unless you enshrine them into xref.el. Then you'll get more of > problem 1. Definitely not. Let's keep it minimal. > The only clean solution to this is to go knock on language > designer doors ;-). But I thought we had reached this conclusion > already, why are we rehashing it? > > And if you didn't catch it, the current eglot-find-* commands > can be cleanly implemented with no hacks and with a common UI > between them. > > Just like the Eglot code-action commands for common actions such > as "organizeImports", "quickfix". > > 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. And I'd like the same for these xref commands. (but not for Eglot and LSP's sake! My inspiration for making this thread is not Eglot and LSP, it's my own xref backend which also has these concepts) >> Practically, I don't want to have a different UI for these commands in >> every individual language and mode, I'd like a common set of bindings >> which are usable for every language which supports these concepts. > > And I'd like speakers of foreign languages to understand Portuguese > "go there go!". And I yet I fail, and it's impossible to explain. > > >> Which I think is most languages - including Elisp. > > "declarations" really? Sure you could cram declare-function into > there, and it kind of emulates the forward-declaration meaning of it > in C/C++ which is clearly LSP got the idea from. Fine. But then what > about compiler-macro declarations and edebug declarations, etc, the > ones you use with `(declare (debug...))` in the beginning of functions > (sometimes not)? They're an entirely different concept and yet known > as "declarations" for any Elisp (or Common Lisp) user. It's awkward to > find both mixed when you're thinking of just one. That's not what I'm suggesting. I suggest that find-declarations when run on a generic should give the cl-defgeneric, and find-implementations should give the cl-defmethods. 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, and an xref-find-methods which in Elisp jumps to the cl-defmethods. When run on regular functions, both will just jump to the defun. And I would like default keybindings for those, ideally under M-'. I think this is useful independent of anything else. I want this purely for programming in Emacs Lisp. If and when we added those, I think it would be reasonable for some language modes (but not others) to connect xref-find-generic to LSP declarations, and to connect xref-find-methods to LSP implementations. Since in some languages those concepts match up decently well.