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 refactoring capabilities to Emacs Date: Wed, 30 Aug 2023 03:52:44 +0300 Message-ID: References: <83fs4f36wi.fsf@gnu.org> <61621120-8f6d-5884-e7c8-33581b8e0ca4@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="24358"; 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: Yuri Khan , Eli Zaretskii , emacs-devel , "Philip K." To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 30 02:53:51 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 1qb9Sw-00068h-A4 for ged-emacs-devel@m.gmane-mx.org; Wed, 30 Aug 2023 02:53:51 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qb9S9-0003fy-IB; Tue, 29 Aug 2023 20:53:01 -0400 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 1qb9S2-0003fj-Rl for emacs-devel@gnu.org; Tue, 29 Aug 2023 20:52:54 -0400 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qb9Rw-0001jl-Ln; Tue, 29 Aug 2023 20:52:51 -0400 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6D1FA5C01A3; Tue, 29 Aug 2023 20:52:47 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 29 Aug 2023 20:52:47 -0400 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= 1693356767; x=1693443167; bh=kxzhRpE1PKu6TUb6KSNEOoGzvGwWcNJb8MN oGHvsjVs=; b=lBENNLLR1XI0JFABmS78CqVlPSVDaHV1U10VJVEn/YuuTQq9GCN WXy4Wuu/U5tSVgUrVdunG8kS8gWbtgHb9UkJsat4WiSC3aSHcESb+cHKcwLRt6dr 7+DVJIcBJkv0aIpBwYHhzj4zRM46thx/ZLodCmn80WNOEgMbfSLTUojGlg97XWL1 keUZ+XIJVBo6NQooqWioD125HEPLpQGyKYKUuwghbyz0b/nyIRP4K2VDalGTk7L5 Tzm+JqPmuccop1NS+FVTOMuzC3MSec72Cn/C7ZxP9epebI/1yu7PdomGz5fKU0cx 84QjGthTCGBrK8oyBV8mQQhxnf4DwhGuqxg== 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= 1693356767; x=1693443167; bh=kxzhRpE1PKu6TUb6KSNEOoGzvGwWcNJb8MN oGHvsjVs=; b=fYjQYxynpqQxw/vHSvJeyZHS6mh0dID+suHVKU48D3O640vEdul N8gba/v8+Zdeh+Zk1fgVVNEpZs5bXI4cVHlYB02fyt9WjkwRtoZLpmg+obftFw21 YBHSXv76qW9nR/nx+7PXXXD0cjORVAvEXHoV6RVdH2OKw5D9Uz+P41bNY+3tHkqx qu4qWg+T0EAjMq1mV6uQw9fMMQkn87qsFDHSoL4tRc1bcHq5/HKu/5VEudmLrXH/ 9UmbYi4/2pqqRdBqQxruLfI+H2hA1oNYXoDx6OYA5/B3p5kx/TfQpRaVJN3+eeHw WX36Ndi33bNQtI1B3YwLtQLPlLrNRTKrFbA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudefjedgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepledvjeeuhfffueekkeegkeeugefhfeejjeffveektddvgeetteevueevkedv teffnecuffhomhgrihhnpegsohgssgihhhgrugiirdgtohhmnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdgu vghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 29 Aug 2023 20:52:45 -0400 (EDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=66.111.4.28; envelope-from=dmitry@gutov.dev; helo=out4-smtp.messagingengine.com X-Spam_score_int: -39 X-Spam_score: -4.0 X-Spam_bar: ---- X-Spam_report: (-4.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=-1.242, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 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:309521 Archived-At: On 29/08/2023 13:53, João Távora wrote: > > On Sun, Aug 20, 2023, 23:52 Dmitry Gutov > wrote: > > On . > > What we don't have is any advanced UI coming with that. Traditional > IDEs > (and apparently even VS Code now: > https://bobbyhadz.com/images/blog/rename-variable-vscode/refactor-preview.webp ) > have been featuring the "preview changes" feature for years. One where > you could see which files will be affected, and even opt out from some > of the changes. > > It seems like the LSP protocol provides enough information for this to > work (the response to the "rename" action is a list of changes to be > performed on the client), so the UI can definitely be extended there. > > > Philip K. has proposed a patch to Eglot that implements this in > bug#60338.  It is not without problems, but was generally agreeable to > me. Would you have a look, Dmitry? We stalled while thinking about the > user confirmation model... Hmmm. Some screenshots would go a long way, I haven't tried the patch yet, but from what I can tell from the description, it's a pretty power-user-ish approach to UI. Similar to what we ended up doing with checkin-patch in VC -- powerful, but no very obvious to a non-pro user in how it can be operated. It is surely a good addition to Eglot, but the refactoring interface I was thinking of would have been more graphical (very vaguely in the style of Xref), looking a little closer to the VS Code screenshot I posted. But those are just my expectations -- opinions welcome. > Anyway, are we aiming at making Eglot and LSP the only provider of > refactoring in Emacs? If we aren't, then I think we should be working on > a compatibility layer (which can be modeled after LSP's request/proposal > mechanism) even if -- for the time being -- LSP/Eglot is the only > provider. That move would inherit a lot of code from Eglot related to > applying the changes, confirming etc, meaning those details would > already be solved. We have refactorings in various places: as Arne mentioned, there are some established third-party packages, of different degrees of popularity. And from built-in ones we also have, at the very least, some commands which present long lists of search results with Xref interface (some plugged into by Eglot when it's enabled, and some not), those could also use a better interface for global replacements. Regarding compatibility layer, I'm not sure I see a request-response mechanism here. I'd expect to see something synchronous, e.g. a call (refact-start CHANGES) where CHANGES are a list of changes in some pre-determined format (with file names and buffer/byte positions or lines and columns). Then the UI takes over, shows the user the proposed changes, allows paging through them, maybe disabling certain ones (for all changes in a file, or all files in certain dir, or individual changes too), and applying in bulk after a confirmation. Maybe a callback at the end could be useful, though, e.g. to update any views that need to be updated. Could always be added later. And here's a general question to such UIs: what happens if one of the changes (in the middle of the list) becomes un-apply-able. At which step the user finds out about this. I don't have this solved very well in xref-query-replace-in-results, but an attempt was made.