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 12:45:27 +0200 Message-ID: <2ed0bdaf-f749-90d1-edef-6c650f00a556@gutov.dev> 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> <87il697r5g.fsf@catern.com> 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="19972"; 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: Spencer Baugh , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 11 11:46:31 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 1r1lVW-0004zD-10 for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Nov 2023 11:46:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1lUh-00046h-Cx; Sat, 11 Nov 2023 05:45:39 -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 1r1lUc-00046V-Ln for emacs-devel@gnu.org; Sat, 11 Nov 2023 05:45:34 -0500 Original-Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1lUa-0005CF-Pa for emacs-devel@gnu.org; Sat, 11 Nov 2023 05:45:34 -0500 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B33EE320095E; Sat, 11 Nov 2023 05:45:30 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 11 Nov 2023 05:45:31 -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= 1699699530; x=1699785930; bh=f0Xbww9zR+wmgMMI6wejKFQyZbV0v4No1bB kLUIr0w4=; b=Ug2IezgMmL4QVjCdNuYzsVWBoxg/NiPWL3b9ZV8RPlVBSstbHqC 8os3uMsp7T5LXbubNyQXikjmvoy+NHOzqWdZec/GlRreC4GC/XzjjCuJYbuj659r JySAP//ajH0DJvdhNAuGlt3M09mEjnDKiSOLnert1LyI2fZ19RGrpXllkktgIr/4 oM9m31iBkdQGQVpjtopDzMLcFyRb84jN+hUvPxX9aaPGRPqH1xo8t18nRWznX9WI Rvi+vkR78+QZ8J9Wywhpur+29xlUfx7CjM3EyScC4TuKu+7DPmiarOyLTfDGxcC5 2QikLMqtRQV+HLG3a2UAv7j5LLyLSi9H5RQ== 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= 1699699530; x=1699785930; bh=f0Xbww9zR+wmgMMI6wejKFQyZbV0v4No1bB kLUIr0w4=; b=SA6f5xaY0qmCaYG6yeYsFnzqx6jmyGTBv8vUVf1AqKbI8yQ8+ce Xx+iQCL7vopJTm7VdKs9oUkwKguOLMi+N6qJjrbD0gJf0spR5z3/ksKn+ws5bxYX rN80yTieZOIg/k1JkP4U1I8CZbjeheij3UgO76fyTvr3YO5e97qcIjIsZhwMU4Xf Tmw6GKfHlmiP1dOfmvalvzGVKRFIbH2uUHMX2QOX6HHRziLPivvPje2zRTwMuMMw LME5ivyzkTu01oApIUt+g5zMeRpRxtwiokAs2iYNKqhzMI8xYRipRlodSy/n87i2 xFk9oe8U610hAyHMKdjtMh6MCw3+KNB/ayg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddvhedgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 11 Nov 2023 05:45:28 -0500 (EST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=64.147.123.24; envelope-from=dmitry@gutov.dev; helo=wout1-smtp.messagingengine.com 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, NICE_REPLY_A=-3.265, 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:312537 Archived-At: On 10/11/2023 19:36, Spencer Baugh wrote: > And refactor-code-actions will behave like the current > eglot-code-actions, and prompt for code actions iff there are multiple > possible actions that can be taken? I know you prefer that workflow > personally, but some people like keybindings to do common tasks > directly. > > For example, do you expect to support symbol renaming in refactor.el? > That if anything seems like something which deserves its own binding. I think the plan was to have a binding for refactor-rename, and dispatch the rest of action dynamically. > That being said, maybe we could have mode-specific commands and bindings > for these things. So if something is supported in a language, a major > mode could make a binding for that. And then, just, we might encourage > using the same bindings in each mode that binds something. That could be discussed. >> But I think we have made both our positions clear. I understand what >> you want to do and I am completely against it, but this is not just >> up for me to decide. The only thing that is, is that if I like the >> new interfaces in xref.el I will implement them in eglot.el. The >> UI that xref.el provides I can't control. Of course I recommend >> keeping at least the current UI of xref-find-extra, not least because >> it's something that has actually been implemented and I have >> spent time integrating. And I also like your idea of KIND=nil to >> make it show a sectioned listing using whatever kinds the backend >> declares as section headings. > > OK, fair enough, and I can see your point. I think we're both clear. > > Putting any talk about common xref APIs aside... Just to be clear, my > understanding is that you have no problem with the idea of: > > - Teaching the elisp--xref-backend about separate 'cl-defgeneric and > 'cl-defmethods kinds, which return the obvious things > > - Adding commands elisp-find-cl-{defgeneric,defmethods} which use those > kinds (and which fall back to the regular definitions) > > - Adding bindings in emacs-lisp-mode for calling those commands > > I'd like to do that independent of whatever we end up with, so just > making sure you're not opposed to that, even though you might not be > interested in using it. I think your idea of using xref-find-declarations/xref-find-implementations for that would be a little more compact. With a user option or not.