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: Thu, 9 Nov 2023 01:34:38 +0200 Message-ID: <2d964697-2b4e-64c7-2f16-aae87e57def4@yandex.ru> References: <4639d7ca-2109-864c-33c0-38e65f26f262@yandex.ru> <835ybb3txt.fsf@gnu.org> <83wn3q311i.fsf@gnu.org> <412afa2d-5dbc-52da-39c4-99be3873929c@yandex.ru> <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> 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="7404"; 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: Eshel Yaron , Spencer Baugh , Eli Zaretskii , stephen_leake@stephe-leake.org, john@yates-sheets.org, rms@gnu.org, fgunbin@fastmail.fm, casouri@gmail.com, emacs-devel@gnu.org, azeng@janestreet.com To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 09 00:35:54 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 1r0s5R-0001j8-ML for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Nov 2023 00:35:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0s4Y-0003ov-JE; Wed, 08 Nov 2023 18:34:58 -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 1r0s4W-0003fS-VO for emacs-devel@gnu.org; Wed, 08 Nov 2023 18:34:56 -0500 Original-Received: from forward502a.mail.yandex.net ([2a02:6b8:c0e:500:1:45:d181:d502]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0s4T-0001WV-Qt; Wed, 08 Nov 2023 18:34:56 -0500 Original-Received: from mail-nwsmtp-smtp-production-main-17.iva.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-17.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:96a1:0:640:9109:0]) by forward502a.mail.yandex.net (Yandex) with ESMTP id 9CB716138F; Thu, 9 Nov 2023 02:34:47 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-17.iva.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id hYn9cJ4UieA0-m1gx197X; Thu, 09 Nov 2023 02:34:46 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1699486486; bh=LgFUAGz3KDsTfAv6HuxBNcvt2AAX+DnxnH4E080EoBg=; h=In-Reply-To:From:Subject:Message-ID:Cc:References:Date:To; b=jGL9KBi9EaSwz5m7Zu26WWmulsIZ9mMM4iVG7esV58rzzhzIqYJHtUEF9Cm4qbnDm /j5bmu9ogXsuuTxsRa/kH+hgFsgRV3pxFePH0mNf7jODJ5u30Y1+E/re/bIvNOTmrx dAWJ9+aXD2ZbqZd2Yj07HThQ18Cal0KEpP9xSadw= Authentication-Results: mail-nwsmtp-smtp-production-main-17.iva.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 0FEE327C0054; Wed, 8 Nov 2023 18:34:42 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 08 Nov 2023 18:34:43 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddvtddguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegughhuthhovheshigrnhguvgigrdhruheqnecuggftrfgrth htvghrnhepgfejhfduffegvdevtefhgfettefgfeelgfelffehgeehhfeiudehfedvffeg teegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hguhhtohhvodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqddufeeffeelleeh hedvqddvleegjeejjeejiedqughguhhtohhvpeephigrnhguvgigrdhruhesfhgrshhtmh grihhlrdgtohhm X-ME-Proxy: Feedback-ID: ib1d9465d:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Nov 2023 18:34:39 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a02:6b8:c0e:500:1:45:d181:d502; envelope-from=dgutov@yandex.ru; helo=forward502a.mail.yandex.net X-Spam_score_int: -60 X-Spam_score: -6.1 X-Spam_bar: ------ X-Spam_report: (-6.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, NICE_REPLY_A=-3.277, RCVD_IN_DNSWL_LOW=-0.7, 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:312369 Archived-At: On 09/11/2023 01:22, João Távora wrote: > On Wed, Nov 8, 2023 at 10:59 PM Dmitry Gutov wrote: >> >> On 08/11/2023 03:19, João Távora wrote: >>> On Wed, Nov 8, 2023 at 12:33 AM Dmitry Gutov wrote: >>>> >>>> On 08/11/2023 02:21, João Távora wrote: >>>>> On Tue, Nov 7, 2023 at 11:18 PM Dmitry Gutov wrote: >>>>> >>>>>> Joao didn't want to have such definitions in Xref. I'm still on the >>>>>> fence, personally. >>>>> What don't I want? I haven't read this wordy subthread but it seems >>>>> Eshel is proposing exactly what I changed in xref-find-extra: take "kind" >>>>> as argument. >>>> >>>> Sorry: you didn't want those definitions in _Eglot_. Not in Xref, that >>>> was a mistype. >>> >>> Ah. Well, first, it a fact that I _have_ them in Eglot, and I'll >>> keep having them, because they've been there a long time. >> >> The normal practice is to wait a little while until the new "core" >> feature is available for a lot of users (perhaps skipping a few Emacs >> versions, or - more bravely - wait for the next one and then just raise >> the minimum xref version required), and then declare the built-in >> versions obsolete in favor of the upstream. >> >> The period before obsoletion is not as important as the agreement to do >> that - because then we will be talking whether the "proper" >> functionality should be shaped as a number of new commands (one per >> kind), or a dispatching command, or both. Or something else. >> >> For the purpose of such design discussion, simply using Eglot's commands >> is not a good choice. > > I don't get this talk of obsoletion. I don't want to obsolete anything. > The Eglot commands are there because they fulfill a need that > generic xref.el commands will never be able to fulfill. If Eglot keeps its commands (which I don't mind that much), then any comparable package should also be allowed and even encouraged to define its own commands. And we should document that somewhere, too. But that design ends up far from the original "Eglot shouldn't do this" sentiment that I have read before. And also, Eglot keeping its commands seems incompatible with (or at least counter to) the approach where is an existing set of "extra" commands that is bound to some prefix map (e.g. one assigned to M-'). Because if there are many different commands called *-find-declarations, it seems difficult to put them all on the same key. >>> And it's not really relevant that I didn't _want_ them. If I had >>> the choice back then between recommending existing xref commands >>> and adding new commands to Eglot, of course I wouldn't have added >>> them. But I hadn't, so I did. Pretty simple. So I don't understand >>> the argument you're making against Eshel's and my suggestion. >> >> Since you didn't want them and argued that they shouldn't be in Eglot, >> it seems natural to assume that you would be happy to obsolete them in >> favor of built-in functionality. > > You assume wrong, or at least it is not something really relevant > to this discussion. If xref-find-extras had been around at the time, I > would have argued that users could use that or simply that xref > command-defining macro to make their own johndoe/find-thingy commads. > Or major modes could do it, perhaps even better. > > But neither was available at the time, so I did those commands and they won't > be obsoleted any time soon. Reasons being..? >>>>>> Or it would be nice to hear from someone who have tried out Eglot's >>>>>> integration and found more upsides there. >>>>> If you want that to happen, the only realistic way to have good >>>>> feedback from anyone else other than emacs-devel nerds like me and you >>>>> is to release an Eglot version with this feature, which we can change >>>>> later (even non-backward-compatibly, within a reasonable time frame). >>>> That seems like a last-resort type of approach, for this particular >>>> discussion. >>> >>> Not really, just being pragmatic and suggesting a way for you to >>> get the opinions from Eglot users that you wrote you wanted. There >>> isn't a significant amount of engaged Eglot users in this discussion >>> that are going to try the patch. >> >> Feedback is good, but I prefer to arrive at some sound design first, >> even if it doesn't do everything anyone might want. And then test it on >> a wider audience. > > The base of the current design, the xref-backend-extra-defs and > xref-backend-extra-kinds, is more than sound enough. IMO could > some micro-enhancements like better names and support for non-string > kinds, but that's completely secondary. It's not secondary if people will start adapting their backends to it. E.g. the term "extra" seems more like a misnomer now, given that people seem to want that command to include the kinds already present in "definitions". And they might constitute the majority of those "kinds".