From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron Newsgroups: gmane.emacs.devel Subject: Re: Adding fix suggestions to Flymake diagnostics Date: Mon, 27 May 2024 14:15:27 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16003"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Spencer Baugh , emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 27 14:16:38 2024 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 1sBZHK-0003tm-1U for ged-emacs-devel@m.gmane-mx.org; Mon, 27 May 2024 14:16:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sBZGa-0007CD-EH; Mon, 27 May 2024 08:15:53 -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 1sBZGP-00075T-3h for emacs-devel@gnu.org; Mon, 27 May 2024 08:15:44 -0400 Original-Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sBZGF-0001f3-Ko for emacs-devel@gnu.org; Mon, 27 May 2024 08:15:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1716812130; bh=WvViloKIhcdQy0I5GofqzMIWMGMLR6aZsp2OpDtNXa0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lcoAbVHGnIb97cagp022QoXZ6cyRLkhvdyAlYfwTP9inm+epK1BkRBll4hDzvh2++ A2F5U9IAaf4sVT0UKy/aA4VB88G2+BBHn9LLOJxOG3S1Jk1jayVyIIXVs0//trJUbk /z7tsWE4tX+Hksi31j4k4yTj97xcA4jBzbG504uFtRCIkxzVZsiIT9eeVFpE5/5dH2 xozNlI3W1qB4TwHSt1cZs8VpCaIgsZFRO+il6cJEO4nzSqurVWwPiQqMDiykLI20S3 xa3MvXcZSWFCzQqnRLXS2RfxBWrqnXwe/VZ8ua5a2/mqSPcDxODWIisueRb4ADq8Rc YrWIBqwKf3sdw== In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Sun, 26 May 2024 21:24:52 +0100") Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@eshelyaron.com; helo=eshelyaron.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.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, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=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:319606 Archived-At: Hi Jo=C3=A3o, Jo=C3=A3o T=C3=A1vora writes: > On Sun, May 26, 2024 at 4:56=E2=80=AFPM Eshel Yaron w= rote: >> >> Yes, Flymake lets backends associate arbitrary overlay properties with >> diagnostics, but that requires backends to worry about UI stuff. > > 100% Agree. And indeed Eglot would like not to worry about UI, but it has > to on more than one occasion. So if you want to lift Eglot's diagnostic-= fixing > things out of there That's not strictly my goal, although it could be a nice side effect. What's important is to have a good, backend-agnostic, experience for fixing diagnostics. Such a standard UI may subsume some of Eglot's bespoke UI, but it may also be complementary and the two can coexist, perhaps with some LSP-specific use cases only provided by Eglot. > , I suggest lifting them into another library that is *not* Flymake. > That library would tend to be the new refactor.el, which would always > need an "edit" concept of its own (with more or less similarities to > LSP). I don't think of fixing diagnostics as a form of refactoring, rather as a separate activity/use case, even though there's some technical overlap in that both involve applying edits to code. You fix diagnosed issues in response to their detection, while a refactor operation (rename, extract, ...) is something you mostly do unprompted. Therefore refactor.el is not the best place to put something like my proposed flymake-fix, IMO. We could have a separate library, say flyfix.el, and put the fix-diagnostics UI there. We'd still need Flymake backends to communicate with this new library, since these backends are best positioned for providing fixes for the issues they diagnose, but this communication can be transparent to Flymake--for example, it could rely on some overlay property that backends would add to diagnostics and the UI of the new library would look for. If we really don't want to teach Flymake about fixes, I think that could work. WDYT? > I gave your refactor.el a *very* cursory read but it seems to be at > least more or less the length and complexity I envisioned such a > library having. It has its own concept of edit, seems to know how to > present things as diffs, all good things. The tricky part if I > remember was how to talk to the backend about the kinds of actions > available. That's definitely a challenge. Currently I tried to keep things pretty flexible: there are standard operations (so far only "rename", but I'm planning to add "extract", "inline", and "organize" for imports) and custom operations. Backends can say which operations they can facilitate, and that can include both standard and custom operations. For standard operations, the library (refactor.el) takes care of all the UI consideration and the backend only needs to provide data in a standard format, while for custom actions the library gives control back to the backend. Eshel