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 10:06:23 +0000 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: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11821"; 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 11:07:22 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 1r1OQ6-0002nf-6y for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Nov 2023 11:07:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1OPQ-0003Eh-F0; Fri, 10 Nov 2023 05:06:40 -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 1r1OPP-0003EW-AB for emacs-devel@gnu.org; Fri, 10 Nov 2023 05:06:39 -0500 Original-Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r1OPN-0004Rz-Hp for emacs-devel@gnu.org; Fri, 10 Nov 2023 05:06:39 -0500 Original-Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-5098eb6690cso2191112e87.3 for ; Fri, 10 Nov 2023 02:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699610796; x=1700215596; 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=oyQY38UloDbUqhn9YlTVd3sADPB84xJCmtu4bednklU=; b=HIH/aSH7YuE6Agx4+sR4R2leWsnnZHVD/O7Y/JixZeBjOARTN6r4yvrro/jOXMtZCW Zl9M0SBj4kpkEsarRIRcE5S8O0cfFBNTizx7zeBT0/DnEXZMYZG7/HgtyrrEJwyjnR+7 K8WHeqR6fYbusj8CzVfRNQjEWRrzAnZJCu/iH9zImZeE/sx1CU6QGS4uOt2jB2mqozV3 yhXGefL0eQ/L2vmSxYjdG4VWhscZ/sTxUTdIEoIIS2o2CVm5ImfJwQClke9MVIqbDYFe QLcFM4yCDAcncmhvS8QgnnP9hP7Jwfn0pSZ8QDj2PbGQ2A61m4wy16Mj5or77zpHeSMC do2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699610796; x=1700215596; 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=oyQY38UloDbUqhn9YlTVd3sADPB84xJCmtu4bednklU=; b=VjCBMdl9moyHs81M63XFDR9nhZOcEqtsGfBOVEjgbBq3cnDibOypASiOwsCD0pEfiA rmMUF+madpnjcoekLdAKo8ewL21jXe4Cut+HysdxOVtMMXAet+Oz6rHE6H0Gj56kX2fY qRcb2pp5l4pAqXb2+57ldivj/Yj6PE47t1e2qUBIL4z+3mKEn2Zft44EA3QkoYN9/gFH F9AaV+dq+n04YJ3Jy6K71A55DtgtqQj1qOoVNaAbM9uVDsabsJOU3LlQN3Fyl9ufhJpn 2TszsKmoMUHcaFdhXI5dC1VTuqmnlobeLHTF8Cmer//3yOmuINzxAJDZTG4B09ZkDBkO +iDw== X-Gm-Message-State: AOJu0YyL6wHgjbm8MXalrZaxK4j++fubjTFWs7Uog1MYMEXQfmUQ9kxZ nU2O4P4PhLjW0UrPxRMco4Ie4aEeP7sDGStDboA6a6D7h5y13Q== X-Google-Smtp-Source: AGHT+IGkRzYzeBTqK7QHGqKjg2tHwBmW78ZU2k8d6TRnob0hxEmjtjrhIVa0QqUh9D1wne8gFDvv4umk2qrq7SHo0D0= X-Received: by 2002:a05:6512:3482:b0:507:a6e9:fbba with SMTP id v2-20020a056512348200b00507a6e9fbbamr3208513lfr.63.1699610795442; Fri, 10 Nov 2023 02:06:35 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::133; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x133.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:312468 Archived-At: On Fri, Nov 10, 2023 at 6:23=E2=80=AFAM 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. 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. 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=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. 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. Unless you enshrine them into xref.el. Then you'll get more of problem 1. 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. > 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. > 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. This isn't an Eglot/Xref, etc problem. It's a problem of whatever you are trying to do. Eglot uses no keybindings and plans to keep that promise. Then, there are keybindings reserved for users, major modes, specialized modes, etc. I don't know the rules by heart, you can consult them. Jo=C3=A3o T=C3=A1vora