From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Sat, 11 Nov 2023 23:37:17 +0200 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; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17648"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: Spencer Baugh , emacs-devel@gnu.org To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 11 22:38:21 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 1r1vgI-0004Im-Ty for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 22:38:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1vfR-0003qV-MG; Sat, 11 Nov 2023 16:37:25 -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 1r1vfQ-0003q5-8c for emacs-devel@gnu.org; Sat, 11 Nov 2023 16:37:24 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1vfO-0005g2-H5 for emacs-devel@gnu.org; Sat, 11 Nov 2023 16:37:24 -0500 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 13CB95C00F5; Sat, 11 Nov 2023 16:37:20 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 11 Nov 2023 16:37:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1699738640; x=1699825040; bh=1H3CqnwnzG/Od86BGXDbFMI4wYpEdAqQKyz CeaAGfbM=; b=r+vmn3fAXGYf1UiPsGSItdEPdyAwRF1Vb4Po5VYPR1zDcj5eAGQ t89T7W5/ECUkRdAig8BINNRup+nzdzPdeG/lH8UmNsIixRYp04NCIO/f6eUTuGhi 0d/73LcI9WAkj7h83JsBmH3wGu/TkDGDnGPjbUlBGS139ZS8ySKwnVodikWs8ZUk 3nduBbPB55rDndXGDpEgtGZkhxbrrv5o61cEcRnwmidD1/GY3fDIsOevhQq61GMV yHf7d+m2uzEo9zVH/Dp7+KdR+3j0yjQX49pv4NKDQvomlWTVAZ4S+l78aD/6sWlq ifUKKtB8x2tG3q0gzkcYMCytbSfnmrrCmNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699738640; x=1699825040; bh=1H3CqnwnzG/Od86BGXDbFMI4wYpEdAqQKyz CeaAGfbM=; b=tqzT/K1S2phAj3zgzen8byQ+9L86JEXYyWwJ/RC7RT15qZ2U2p/ LamTQuloLg7pQTrhZrM0XFAw26atmohfW1fqujV3J8OlEdzF21DrMby3dcEXR+pg biARjeOmTw9Yu3r5qJgVD7ZfOLKu2S2gxCv2/giTg+VVIR+oe5iDRGbp/3Fu/ixi e/K5SW0Ikm5YK/qpkk+0PkrKUT2JZOWK6Y7c49nF4hMb0jyEaRo2LP9/tpYl+YhA avZcTr+rhlGFTkTi3RjPBM0KyXCi6i7xNabtrgGC8uKJao4ylc3sMZGG3uu6ZGXd yaxLUBCWicOG8tAIbjwIXEap7vVjrdddWyg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddvhedgudehudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffg feejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 11 Nov 2023 16:37:18 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=66.111.4.29; envelope-from=dmitry@gutov.dev; helo=out5-smtp.messagingengine.com X-Spam_score_int: -69 X-Spam_score: -7.0 X-Spam_bar: ------- X-Spam_report: (-7.0 / 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, NICE_REPLY_A=-4.148, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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:312614 Archived-At: On 11/11/2023 13:44, João Távora wrote: > On Sat, Nov 11, 2023 at 12:58 AM Dmitry Gutov wrote: >> >> On 09/11/2023 22:44, João Távora 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 made >> 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 of >> 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. >>> 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. Declarations might be less of a thing in some of those (mostly dynamic ones), but overall the list even makes a certain sense for Elisp (and similarly CL, I guess), at least in the OOP parts of them. And where they don't, one or two of these commands will fail to work, big deal. What's the alternative? To have many similar commands ruby-find-implementation c++-find-implementations python-find-implementations js-find-implementations 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. > 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. Elisp's bag is different in that it will have separate kinds for faces/features/methods and, potentially, variables as well. But those are already in find-func.el and don't need new bindings.