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: Fri, 10 Nov 2023 13:59:10 +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="34095"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 10 15:00:31 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 1r1S3i-0008j8-SX for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Nov 2023 15:00:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1S2j-00069t-RN; Fri, 10 Nov 2023 08:59:29 -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 1r1S2h-00069a-Fk for emacs-devel@gnu.org; Fri, 10 Nov 2023 08:59:27 -0500 Original-Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r1S2f-0004JF-7x for emacs-devel@gnu.org; Fri, 10 Nov 2023 08:59:27 -0500 Original-Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-5098e423ba2so2718976e87.2 for ; Fri, 10 Nov 2023 05:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699624763; x=1700229563; 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=tSuDzGdOS9PLNdBIZmXrhztI0k6SieOHGGaw3zJv104=; b=NkzYm21bLm14jUhGvKCUDwbO2vtesYcmu/XrVjfcCpnqJYR0fWJ27V2jP7kz1r+Zv8 zEOzq115fi6tqTEyt5VEJE8e0lsC4WW+LcYV0H5iEQ8gsMKl4CWVULQWuRkugchaBjMV 5ns9sIVVSAYOqv9ymHSvAbX0bCsrkhiIn/9hr0KMGfGernnYAIU25sOyg7jdsgqdJTu4 K31+kKXYfkVRn6yr1W+UEOW35p6gSkEHWimQpsxQjX28cpW2ftzsu5ZLwEB2SHnTJZRK jxaxBOl7usGGFmk+NhdBSI++juQY1DEIVqIB6AICDDDUPjNpoxKAnYzyfhyXS7OtqWqM kdcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699624763; x=1700229563; 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=tSuDzGdOS9PLNdBIZmXrhztI0k6SieOHGGaw3zJv104=; b=d66UA4fWGiUhkWpzmYQOQtMPVmmL0F883e0QFV1AFSH5fLO7mihyxhBNbiuPoj3mBe /+Z6DtvT3/KAFqeGvjA4IqwUZr3Ce5FBzwKvkJre9fO7Y6Cs76aQckObOiHw1DFROMgm pD6m/M/H34XspyFLBGQF+JwaiK6IOIrZVReG20VqBLN4s8RIvWxc5I62NKoCJqT8dD/z l+cDgotN9aFqtTF4gqlbtruAvhm8CN5KZF88bOFRGeqWfE4XTFwnT94n3k+aCnwSCbN3 Ef8eFNg7cD9KMyBm8uMjFZnQ/bKUtmzgguS7EqUWHMMShcwbHqGZpeyi0cI++hvvT2aw m+FA== X-Gm-Message-State: AOJu0YysLA9Zhap3vnVsneiMQhVXJz6yeJg9gPAhHrQ77NQ4wZgxlGvG OOT6RhghI6kPkl6jVc8RzYhVuvyJa/ueQaBsPKuKjmTAAALsaw== X-Google-Smtp-Source: AGHT+IFMEJUsF8ErIMXEsw5ZVe1LiiYCEhltZCZrSzb4/kM75TlB7GkRQCRCz4ToBcn77NAHaO4pgJjv09OgueKFoqw= X-Received: by 2002:a05:6512:2011:b0:505:6cc7:e0f7 with SMTP id a17-20020a056512201100b005056cc7e0f7mr3793334lfb.44.1699624762469; Fri, 10 Nov 2023 05:59:22 -0800 (PST) In-Reply-To: <87il697r5g.fsf@catern.com> Received-SPF: pass client-ip=2a00:1450:4864:20::134; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x134.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:312490 Archived-At: On Fri, Nov 10, 2023 at 12:15=E2=80=AFPM Spencer Baugh = wrote: > 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. Not really. "Declarations" don't make much sense in Elisp. I'll explain below. And I don't think we should code xref.el with "selfishness" in mind at least if we're serious about making it reusable. elisp-mode.el should have things that make sense fo Elisp. Vast amounts of Emacs users couldn't care less for Elisp, and that's fine. > > 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. Doesn't mean it's any good either. Emacs precedes LSP by many years in being flexible enough to support many languages. And it absolutely trounces LSP in that respect. LSP's main point here is that it supports many editors, and so reusable language servers appear for many languages not motivated by Emacs, and Emacs, using Eglot, profits from that. But LSP makes tremendous tradeoffs in flexibility, tradeoff that we don't have to make or even consider, because we support only one editor, ourselves. > > 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 sugges= t > >> 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=3Dimplementation 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. Exactly, and you wrote "the backend just errors when kind=3Dimplemetation" So you admit it's going to happen. > 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. Yes, the notion of definition and reference are much less controversial. > > 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. But incomplete consistency contains, by definition, inconsistency! IOW "degree of consistency" is a fine example of an oxymoron. > > 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-extras= , 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. > 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. Doesn't make sense to me, sorry. In Elisp you work with symbols. So a given symbol has many possible meanings (a so-called lisp-2 has two standard ones: variable and function bindings). But you can add your own, class definition, generic function, setf expander, autoload-function, docstring, whatever crosses your mind. In current Elisp-- but not necessarily future Elisp--you alreadyhave two completely different concepts of "declaration". One is declaring functions early so the byte-compiler doesn't complain about them and another is optional `declare` forms you fin= d in the first form of a function's body. Completely different concepts, miles apart. Now you want to add a symbol's generic function definition to the "declaration" family. Even more miles apart. So one day I find a symbol, I press your desired xref-find-declarations on it and I get this awkward salad of totally unrelated things. I'd certainly like to be able to use xref to find the source code loci for all these different things that a symbol might mean, of course I do. But xref-find-declaration is a awful way to do it. Mind you that xref-find-references is much less problematic. A "reference" is in essence any manifestation of a given symbol/name/identifier in the source material, _regardless_ of the specific kind of manifestation. > 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. In the end, people will be able to continue using LSP and xref.el without any problems, with eglot-find-declaration, etc, that's a given. Joao