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: Thu, 09 Nov 2023 16:11:37 -0500 Message-ID: References: <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: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19381"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:KxVH2k8W5oCsfkN4TpIvV6o7rzg= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 10 07:24:28 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 1r1KwN-0004ku-Oe for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Nov 2023 07:24:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1KvX-0001MC-RM; Fri, 10 Nov 2023 01:23:35 -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 1r1CJg-0000Ul-O7 for emacs-devel@gnu.org; Thu, 09 Nov 2023 16:11:56 -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 1r1CJZ-0004mY-Ey for emacs-devel@gnu.org; Thu, 09 Nov 2023 16:11:56 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r1CJW-0006x2-Bi for emacs-devel@gnu.org; Thu, 09 Nov 2023 22:11:46 +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 01:23:33 -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:312459 Archived-At: João Távora writes: > On Thu, Nov 9, 2023 at 7:23 PM Spencer Baugh wrote: >> >> João Távora writes: >> > On Wed, Nov 8, 2023 at 11:34 PM Dmitry Gutov wrote: >> >> > 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? >> >> Right, so if we have kinds defined in the core for "declaration", >> "implementation", and "type-definition" (maybe not with those exact >> names), then we can have xref-find-declaration, >> xref-find-implementation, and xref-find-type-definition (again maybe not >> with those exact names), and just do >> >> (define-obsolete-function-alias 'eglot-find-declaration 'xref-find-declaration) >> (define-obsolete-function-alias 'eglot-find-implementation 'xref-find-implementation) >> (define-obsolete-function-alias 'eglot-find-typeDefinition 'xref-find-type-definition) >> >> Is that possible? > > For Dmitry to answer, but I think we had established that is a > slippery slope. Many languages have different exotic concepts, like > Lisp and macroexpansion, C++ template instantiations, or annotations. > > And conversely many other languages don't even have the distinction > between the three you mention. 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. > And i'm only talking about the handful of languages I'm > more of less familiar with, there are many many more. And many > more can be invented with different types of manifestation, there's > no shortage of imagination is language designer-land. > > Not to mention Xref can in theory be used to provide > cross-referencing support in any type of work, not just > programming. > > So I thought, that about 6 months ago we had established that > "definition" and "reference" are two relatively safe concept to > keep in xref.el, but other concepts should not be in there, > because this doesn't scale well and could imposes awkward > structure and hacks into an unknown number of backends. 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. Likewise other backends which support something they want to call an "implementation" can support 'implementation. We don't have to say what an "implementation" is, any more than we currently specify what a "definition" or a "reference" is. 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. > Has everyone changed their mind? What exactly bothers you > about eglot-find-declaration/implementation/typeDefinition? > In LSP-land these concepts _do_ make sense, because the > LSP standard prescribes what servers should do with them. > > What practical problem are you trying to solve? 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. Which I think is most languages - including Elisp. There's also bug#64714 - I have to pick bindings for these commands for my hundreds of users, and I don't want to pick ones which will conflict with later changes upstream. I expect there will eventually be bindings for these commands in Emacs. So I'd like to just do it now.