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: Wed, 8 Nov 2023 01:02:20 +0200 Message-ID: References: <861qm4tkih.fsf@stephe-leake.org> <71ea5e83-183f-2ae3-8146-6a31045a0309@yandex.ru> <834jqzafse.fsf@gnu.org> <83h6uv47e8.fsf@gnu.org> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10651"; 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 To: Spencer Baugh , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 08 00:03:19 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 1r0V6L-0002UE-El for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Nov 2023 00:03:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0V5b-0003hr-J9; Tue, 07 Nov 2023 18:02:31 -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 1r0V5Z-0003hT-Il for emacs-devel@gnu.org; Tue, 07 Nov 2023 18:02:29 -0500 Original-Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0V5X-00050a-H7 for emacs-devel@gnu.org; Tue, 07 Nov 2023 18:02:29 -0500 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 52F833200903; Tue, 7 Nov 2023 18:02:24 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 07 Nov 2023 18:02:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=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= 1699398143; x=1699484543; bh=BD7cJjIC6OcWtuALoRuytmH/D8jHVPZu2az W+OGz+/s=; b=Os+lGmdzcatMGFjU3vFFCpBatfT293e8b1m2x3yO1otII9dUhLM mV/YsGkoB/X/HLvWwXG9DfMcodHBZtF9A9fiyM1+Mccg4zOKG6XS0zOZMIER8eBk invTBI7/puK/XJ2ZVSmyUc6Z9ii5XEi/vRobuVS5lcDjW+i3rEcqeNZdUu58vyG/ z9lcVdvoZbdadQvEgkhgdkF8+o2vR9HTMy5nCu/JxCncPKcjsFgOuQ1RTlXLbkw9 DnN0hpeN1lcRxmYdt7zHtAI2ihkIgdC3Y0a1xGkHIACGQBtEU/pB1CB7GGW6ZGvG AQrXaWQhSCNgxxs5gNz/yhAZv3r4UNsNuEA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=1699398143; x= 1699484543; bh=BD7cJjIC6OcWtuALoRuytmH/D8jHVPZu2azW+OGz+/s=; b=E 5AazrSOP4aiDHnMht+urit8DIWdQKuUlADQ4Vo2sB2Kc9b2rb5uJjj9NEX/EPSq6 kwtU7Asm5kI5Ezq2PPu6V+NXlMSTAesR2nBIIyvKqSSM3gTUmhQT9OI43ZUAysMT K5Zyu/6DD6wGgR9/QPqNWTjv7dU6mvTFEfNOdU/yRTUWzQIUxvN3uh7KEe5Wmf/k T+Dj7iYnqUsCZXR8s9lkwVjPMa8NkqdPZsBmbhPo6e+VTyAXy8hu9gMlckfrCUaU KbibMBgZEyh2XKEbZYvyQl5Eq0NsdB5ZHRojtEK2Gq+69kNmlHMlkIMTkIgakbn6 Dta64mkaZz8kTLfFaZnTQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddukedgtdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeghedthedujeeiteeutddtjeekheejteeukeehffdutdejuedvfeevueeviedu udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Nov 2023 18:02:21 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=64.147.123.20; envelope-from=dmitry@gutov.dev; helo=wout4-smtp.messagingengine.com X-Spam_score_int: -51 X-Spam_score: -5.2 X-Spam_bar: ----- X-Spam_report: (-5.2 / 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=-2.344, 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:312325 Archived-At: On 07/11/2023 19:09, Spencer Baugh wrote: > Dmitry Gutov writes: >> Still, though. It's not clear to me that improving this particular >> feature for Elisp will bring a lot to the table. >> >> Does it really do certain things better than simply using 'M-.' and >> then choosing between all the available definition types inside the >> buffer (and then navigating to one with TAB)? >> >> Or if one prefers a more dynamic interface with completions, (setq >> xref-xref-show-definitions-function >> #'show-definitions-completing-read) could fit that bill. >> >> There is a tradeoff of not being able to just press a single char, but >> OTOH one doesn't always know which definition kind they want in >> advance, and here, the full list helps one make that choice. > I guess one possible issue is that requesting all definitions and then > choosing between them could be expensive in certain languages. Knowing > what kind of "definition" you want in advance could make things faster. > I don't have any concrete example of this, just putting out the thought. Indeed it could, but is that a practical concern? For certain languages, or large projects, or etc? In general, I'm not a fan of solving performance problems with requiring more manual control on the part of the user. We can do that, but hopefully only when there really are no better options. And making the choice which kind to search for might save the machine 500ms during the search while requiring the user to spend several more seconds typing and thinking. I was hoping people could try out my patch, and Joao's addition as well, and perhaps report with concrete examples. And arguments can be unrelated to performance: e.g. certain "kinds" might really be unsuitable for the default set. Perhaps "find implementations" might fall in this variety.