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: Sun, 12 Nov 2023 18:59:19 +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> <11b5a8be-b15c-f275-d84a-89c2a3a513f7@gutov.dev> 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="8215"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Spencer Baugh , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 12 19:57:32 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 1r2FeF-0001ul-1P for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Nov 2023 19:57:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r2FdI-0007ew-34; Sun, 12 Nov 2023 13:56:32 -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 1r2FdH-0007eo-FN for emacs-devel@gnu.org; Sun, 12 Nov 2023 13:56:31 -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 1r2FdF-00063b-Ee for emacs-devel@gnu.org; Sun, 12 Nov 2023 13:56:31 -0500 Original-Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-5099184f8a3so4618220e87.2 for ; Sun, 12 Nov 2023 10:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699815386; x=1700420186; 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=wDrtRpUPo2uwhwgPh9M3U0ErRxLk3sZSQcQyAc/lSUk=; b=hjAs6ZXbfcmFqxIz2PuI+noiMQ0FXXuyHcm1pvpe3fSNFVWquuB/NvnEyBVereydti P2tk+ik14GNbcWEQMwk7Cc8RiCylBMTHSrVINGC5+XzW3wadXXxI9hOAP5oVfKzJ1Pzb eBagC0VxN1rQ0b+MIPNvFquDmL2oy+jCqopEkl/Wd+WeXJ7CSZ26Wsh+M74XhqBsTA0g 0vaAmhswYsdG206MTxe39JyZIa2ABTGXmP8LQKIgRCV10lm7+Vx/LS7UPIF12A/Q+vGB YbIbmP052FpkzjKUHk2H7OtfOXAV/rTEQDD7e7hfOA05Q0nhMRgQpATdoAtKJ8AXLJp5 g2CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699815386; x=1700420186; 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=wDrtRpUPo2uwhwgPh9M3U0ErRxLk3sZSQcQyAc/lSUk=; b=bGf+c7kKQjLWMDw6T0LHzeRFWpImj7DWNeDU/0VRg3UTg5kP0h4vaAe2Oeg7GIPa4/ JsQUYVesVRMwpfY8jf219X62dV4KHJJyZODbMsLTLBv2QJ9Sz9Tn8pMfoAAbMZUmWRDt rxd5t1n0MLCg72vIRLxD4yk6lzALyoy8OF9tRVDdHdyxmYliyUNKWgRsi2Os2F3iHDW6 lt0ydcceo5WB2vjhMdChJjy4TR3e/rIT8STNChp82DZmWhQQV6i1t/jVyJmynmdiEmhE hOH9OOK1CfYiNOZBluVO+tfsAw3IrxHhXQazBvAt+hdGv12zeyOlK2VAoT5rY8+w95zB mboQ== X-Gm-Message-State: AOJu0YwnGLN0Oli3QVnjHrS7G/54bd8xH76hIpIUmob4/ntXbM3D3raX 89rWqFJR3++yEUW+GmVmOlQzkABGS1wdLY0F9Yt+GZIQgzM= X-Google-Smtp-Source: AGHT+IEC0b4r7psM/cNFGi0s8Z6e964Svxt9pVRbCksNrBlwHysY8HefI+tm5+dtyYw45FN1tVQzmGXc7FrrvkDZYto= X-Received: by 2002:a05:6512:2382:b0:509:1368:ddc1 with SMTP id c2-20020a056512238200b005091368ddc1mr4210478lfv.53.1699815386009; Sun, 12 Nov 2023 10:56:26 -0800 (PST) In-Reply-To: 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:312657 Archived-At: On Sat, Nov 11, 2023 at 9:37=E2=80=AFPM Dmitry Gutov wro= te: > > On 11/11/2023 13:44, Jo=C3=A3o T=C3=A1vora wrote: > > On Sat, Nov 11, 2023 at 12:58=E2=80=AFAM Dmitry Gutov wrote: > >> > >> On 09/11/2023 22:44, Jo=C3=A3o T=C3=A1vora wrote: > >>> 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. > >>> > >>> Has everyone changed their mind? > >> > >> My impression is that the first feedback from our patches actually mad= e > >> people excited about things that _weren't_ included in the > >> previously-discussed plan, so it seems like a good idea to re-evaluate > >> it. Though not necessarily redo it all. > >> > >> Though I guess this particular mailing list might be biased in favor o= f > >> particular type of users (keyboard-driven, faster interaction as a > >> priority). > > > > yeah, the sample size is so small that's it's more than certainly > > biased. > > Most likely. It's too bad our actual audience here is quite small, and > we don't have other reliable ways to collect feedback to prototypes. > > Dropping an implementation into master is one way to test out a > hypothesis, but it has inherent problems: the feedback comes late > anyway, and quite often we'd end up having to maintain half-bakes > features or unfortunate capabilities this way simply because they had > been added and time had passed. Maybe. Well Eglot has a fair enough audience, though not sure for this specific feature. And I don't see any better alternatives if collecting feedback is what we want. IOW, we shouldn't fall prey to "analysis-paralysis". > >>> 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. > >> > >> I think we've actually discovered that these kind of make sense for > >> Elisp too. They might not match the current implementation, but > >> conceptually, in some future, they might. > > > > Yeah, they "kind of" make sense, but not very well and IMHO that's > > not a detail, but a big red flag. It's clear, and I understand > > your point, that if we were to squint to contort to them we could > > have xref provide a consistent "works everywhere" UI. But as > > Spencer noted it would be "works _mostly_ everywhere". And, as I > > noted, the contortion might lead us up awkward alley, such as > > finding a list mixing `declare-function` and `declare (compiler-macro` > > in the bag of xref-find-declarations. > > Why contort? From where I'm standing, > declarations/implementations/typeDefinitions apply to almost any > object-oriented language (C++/Java/Ruby/Python/JS), and even some > functional ones. What are "declarations" in JS, Java or Ruby and Python? Perhaps nothing perhaps entirely different things. Also, there are a lot of sub-kinds of declaration in C++. Is a forward declaration of a type in C++ also a "declaration" here? What about a C++20 concept, is it a type definition? No right? Or maybe, depends on who you ask some say it's a type for types. Not to mention I think in Elisp we have at least 3 completely different kinds of "declaration": forward declarations, (declare ...) forms and defgeneric. It's odd to mix them. Anyway, this is LSP's taxonomy so it's LSP's problem (or rather, the problem of the poor servers that have to invent ways to shove things in these categories. But not our problem by and large if we don't let it spread any further than Eglot. IMO Eglot is where LSP ends and Emacs starts. > What's the alternative? To have many similar commands > > ruby-find-implementation > c++-find-implementations > python-find-implementations > js-find-implementations Depends. If you are using Eglot/LSP as a backend, you don't need to. Eglot already gives you the LSP trio. If you are using a non Eglot backend, then yes. If you are using specific backend based on Eglot but with more servers, then yes too, but only for the extra types you support. > that all do the same thing inside: call the Xref backend's "find > implementations" mechanism? It will be especially great to use if some > major mode authors bind that command to one key, and others to another. I don't think it'll happen that often, and xref can define a good prefix map to use. It's unlikely we or major modes would find keybinding space outside such a map anyway. > > And Spencer even wanted to put cl-defgeneric in that bag, which I > > can fully understand, as cl-defgeneric can also be viewed as a > > declaration. But its a completely different concept from those > > two. > > If Elisp doesn't have any other kind of declarations, what is the worry? > Let's put the ones it has. But it does, at least for some understandings of "declaration". And it could get even more. A declaration is of course a reference to a thing that characterizes a part, but not the main part or totality of the thing. Besides the other two I mentioned already, any source code locus setting a property on a symbol could be viewed as that. Are we prepared to handle this? We could be. If we are, do we really want to put this all in a one-size-fits-all "declarations" bag? Jo=C3=A3o