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, 25 Nov 2023 04:20:47 +0200 Message-ID: <90e4b9a7-3b51-587d-e317-b89e5d5464d9@gutov.dev> References: <953056ea-9cfb-34ad-6515-9036633dfdbb@yandex.ru> <2d964697-2b4e-64c7-2f16-aae87e57def4@yandex.ru> <87il697r5g.fsf@catern.com> <87r0kw8nxu.fsf@catern.com> <3fe5a8cd-b355-d7eb-10ad-8846aef3387b@gutov.dev> <878r6mx1xc.fsf@betli.tmit.bme.hu> 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="39811"; 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, Eshel Yaron , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , John Yates , Ergus , Filipp Gunbin To: Felician Nemeth Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 25 03:21:59 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 1r6iIv-000A7c-LA for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Nov 2023 03:21:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r6iHv-0003hD-PA; Fri, 24 Nov 2023 21:20:55 -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 1r6iHu-0003h2-AF for emacs-devel@gnu.org; Fri, 24 Nov 2023 21:20:54 -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 1r6iHs-00064J-GY for emacs-devel@gnu.org; Fri, 24 Nov 2023 21:20:54 -0500 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 483B55C009C; Fri, 24 Nov 2023 21:20:51 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 24 Nov 2023 21:20:51 -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=fm3; t= 1700878851; x=1700965251; bh=Kh5Y2A6A5dFBdEld6McjykBidr1vw38RF+i Fyuu1eKI=; b=YRgXShal4ngDChaltudi/WLgov6W+C0d444M5wAWLKpP/albQL8 qs4QuwY3NXJJ3pABwpL5aHLW/+71/JjFleXygKjwIvJGaBHK1KhyXRYj+lyGsy6D P6HkCHrueW6j3qFfOw7fH6YHbQsMv02Q/7PviXPzyQIDdWQUree2RLpKUa8L9oTg CvhlTOFOQnc32SS1SRIBRall836Na0wLnJiY28KwiYMX6IGYFUid/Wl4b6ght2iS UJoopVQmULfAJZWYMlNk1GRDYnBYg3b9iqJLgcD5s2tSDTA4pnD3bIPPqSKxzqE0 gLouwhvSiNOfjvv9ljkoOTUZ7mFImXpASGA== 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=fm1; t= 1700878851; x=1700965251; bh=Kh5Y2A6A5dFBdEld6McjykBidr1vw38RF+i Fyuu1eKI=; b=aGCbeTMXXaX0LDW+C5/7kdVBaxc+TYnELzlJplsZ/PfBpXqKxn/ rZ1fRO3aLAV/mfvxgF9m1+7ELnW8vLdBTKEHpL5VhhH+1jy9qJEQlvprj7mmkjGt a9V28AddAOdLxD3ho3gHTWu5lWOWKvsUXcwE/v3ZQuYCL2n7MZbm0ZI+H0D/Y5W5 /MbPMdsknls/eJS4CpNGeiSL8Z28ZuypsFw6qn9VD/AEwx5qcCWTcYkjq5AkK25u 8Fj2B735lfptxpuhUxkPa9JXibueyb7PZcABC6mc+xibZcfe3u9Tbgi+0cNMPEbN gjXu0kFryT/DPy+7kT5d7lp5RfcAJal91Fw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehiedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 24 Nov 2023 21:20:48 -0500 (EST) Content-Language: en-US In-Reply-To: <878r6mx1xc.fsf@betli.tmit.bme.hu> Received-SPF: pass client-ip=66.111.4.29; envelope-from=dmitry@gutov.dev; helo=out5-smtp.messagingengine.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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=-1.592, 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:313188 Archived-At: On 24/11/2023 23:43, Felician Nemeth wrote: > Dmitry Gutov writes: > >> Anyway, I've pushed an update to the same branch >> (feature/xref-find-extra). >> >> What does everyone think? > > I haven't followed the discussion, but the extensibility of it is just > great. Here's a refresher on the points of contention, in case you'll have something to add: 1. Whether Xref should have separate commands for declarations/implementations/type-definitions. With default global bindings (probably -- if we manage to get agreement on taking M-', for example). Or e.g. have a registry for kinds and letters, for quick selection between kinds (alternative for completing-read). Or just use completing-read and leave the definitions of all new commands (including the counterparts to declarations/implementations/type-definitions, of which then there will be multiple copies of) to the Xref backends. 2. Whether Eglot should, in time, deprecate its corresponding three commands if Xref adds its own versions. 3. How the new command (currently named xref-find-all-definitions) should behave: should it always ask for the kind, or have a default one (determined how?), or fetch all kinds by default and show them together, like the latest version does. > I think it is a minor inconvenience that it is not possible to use > directly the symbol-at-point as identifier while asking the user for the > kind. That is a prefix argument causes xref-find-all-definitions to ask > the user for both. I'm open to suggestions. Using 'C-u C-u' for one of the choices? Adding a separate command with different behavior (and different binding)? > eglot-find-declaration, eglot-find-implementation, > eglot-find-typeDefinition still use the now non-existent > xref-find-extra. Now fixed, thanks (with a rebase).