From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Adding fix suggestions to Flymake diagnostics Date: Mon, 27 May 2024 15:02:52 +0100 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="24111"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Spencer Baugh , emacs-devel@gnu.org To: Eshel Yaron Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 27 16:03:57 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 1sBaxA-00063M-P9 for ged-emacs-devel@m.gmane-mx.org; Mon, 27 May 2024 16:03:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sBawR-0000hu-9y; Mon, 27 May 2024 10:03:11 -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 1sBawO-0000hK-M9 for emacs-devel@gnu.org; Mon, 27 May 2024 10:03:08 -0400 Original-Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sBawM-0004UW-1F for emacs-devel@gnu.org; Mon, 27 May 2024 10:03:07 -0400 Original-Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-5295eb47b48so3418403e87.1 for ; Mon, 27 May 2024 07:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716818584; x=1717423384; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PsXbMeI8kexRkRtQMjBqqdGwbmYsHRL8/fTMY7O69do=; b=m37yaqDjc7T11XUMLRUKHTrN74hNHpwowlA+3P9vVe4YZtjQOck2XerBqVZ7Ep7SUl 7XLLtP4pwXHIMM3GlCsrsh7lpEZATA/XMZ786lW3LUt0MdAyNdVd5nRtcv9FZeWSn117 NmwD4x+GwGeZDnkMcDXjOaERj9jjgEvycnhDaMumybhnA0J/M9vZxzrFv6W408MzmJA9 IrW4mZMwxNd6cNruNNUdhRVPB/329N5fh9xeB8DUN7OCht84nWOgTihgVBTsdlCuSBzU zmjIwcGU/8lysBB+6JLxAmcS4IREE9oXy8icnoC3QjdC/jsRXbi8jKcuPamBcwCxT32p I73A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716818584; x=1717423384; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PsXbMeI8kexRkRtQMjBqqdGwbmYsHRL8/fTMY7O69do=; b=NjCF7+0yyLQMTzIFLmxNjaND6xJO/VFr+xEQtiHa2kk7JcwfWcplvskCM5XS8IV1xo 5n6VXCd7LNp3XaT9CCDaKwy3UpIWt4U+msVSyJGBmYm+aOMW9r+EJSrjBt3BrlYQeWxT eeoMPKOH2w+tSSXU+yMNxHAcN/PfPraqxXxHCu4NBxPSHICkWRnaZXYnWEeo5Zf3EMyM J0Apal76C2+dnhdvpdYgAtiZMnHj0B0dCyDU/d4SxzwT0vtCxYAkdCZedohg4ookCJch FzxSm9IwQZADTCrR28n9FgNK8H1N9spDEZ8ilSINhrEsEbGt3uNwMnByttCVexC7DsSp k6vg== X-Forwarded-Encrypted: i=1; AJvYcCVBcmDaiQM1fgWFq0NwXJ1IvzAb7SH/ahnUEFjpZ4H0L/pV55b2/5GZAwEka8xHox7XYzobYiVuHobUW6+pxcX7oQGk X-Gm-Message-State: AOJu0YxnKb5QXd8VIHVDpy7R/Lbw2PNQLGuCaPpF5few2jGjiU8Nto9H f++AfpowhMFzscYYYwsdmgAeDZ0tMwkDPxL7elALHSrVIyOeiLW1Z4RnM0m5USB+VHbhVuSfYlw deh9zOfFaw3zJT6Cuo5l2F/+Sx7BiT/Bp X-Google-Smtp-Source: AGHT+IHCXIHBG1sZML/i3BBVUSgMMjyfxoR7Zg0szYGlE86QUQoiIGxLKyGYn7E/HqXLEdHL1GgeH7mZzqYNbXwDtAg= X-Received: by 2002:a05:6512:104f:b0:523:4f64:828b with SMTP id 2adb3069b0e04-529b21fa1femr1556384e87.38.1716818583801; Mon, 27 May 2024 07:03:03 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::131; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x131.google.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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:319609 Archived-At: On Mon, May 27, 2024 at 1:15=E2=80=AFPM Eshel Yaron wro= te: > 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 don't think there's anything complex in Eglot's diagnostic-fixing UI that can't be subsumed by any reasonable interface. > 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? What you're describing is similar, if not exactly identical to what happens today 1. The overlay property you suggest exists. It is 'keymap' 2. it's added to flymake diagnostics overlays via the diagnostic type prope= rty 'flymake-overlay-control', part of Flymake's generic API for adding thin= gs to the overlay diagnostic. 3. The overlay _value_ is a simple keymap mapping the '[mouse-2]' binding t= o a function. I think some users add more mappings to the keymap, which i= s bound to eglot-diagnostics-map. 4. The function is Eglot's. It mixes UI and LSP logic, alas. 4.1 it expects the diagnostic at the mouse point to have a way to "produce" code edits (at first I thought this was async, but you're in luck: it's sync, which greatly simplified matters). 4.2 calls upon this logic to gather said edits 4.3 presents them to the user and applies them. This is UI. If you're suggesting to wrap all this setup in some function/macro of newlibrary.el (the file name for your "new library") so that only the complexity of 4.2 remains in eglot.el, then that's exactly what I'm suggesting. I just note that newlibrary.el _will_ have to know about "edit-producing diagnostics", which means knowing about edits, or at least a way to apply them. It will likely have to require 'refactor.el', which is where the "edit" fo= rmat will live, and call on it to present and eventually apply those edits. In fact, in my mind, newlibrary.el is so short that there's little reason it shouldn't just be a small section of refactor.el. But if it motivates you to start with a separate file, then newlibrary.el (or whatever name you want to give it) is absolutely fine. Jo=C3=A3o