GNU bug report logs - #71504
30.0.50; FR: Fix suggestions ("quick fix") for Flymake diagnostics

Previous Next

Full log

Message #65 received at 71504 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Eshel Yaron <me <at> eshelyaron.com>,
 71504 <at> debbugs.gnu.org
Subject: Re: bug#71504: 30.0.50;
 FR: Fix suggestions ("quick fix") for Flymake diagnostics
Date: Wed, 24 Jul 2024 18:44:28 +0100

On Wed, Jul 24, 2024 at 5:40 PM Spencer Baugh <sbaugh <at> janestreet.com> wrote:

> I don't want to be obstructionist, but it seems to me that if we land
> this in flymake, eventually it will just *have* to be supported in
> Eglot.

Not aware that Eglot is under such obligation.  It generally wants
to use Emacs facilities that do useful work, but only if those things
are simpler than existing battle-tested things.  This is not one of
those.

The patch Eshel was proposing adds a re-representation of
code actions to Flymake, something completely outside its
responsibilities (as I designed and maintained for a number of
years at least).

Flymake's current API is fine for Eglot's code-action purposes.
A refactor.el API would be even better.

> I don't want to abuse that as a way to work around what Joao
> prefers.

I suggested an alternative idea to put in the refactor.el library.  No idea
why that's not being considered : ¯\_(ツ)_/¯

https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg01163.html

Then for sure Eglot would migrate, as I'm always looking for less
code to maintain, not more.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.