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

Previous Next

Full log

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 71504 <at> debbugs.gnu.org
Subject: Re: bug#71504: 30.0.50; FR: Fix suggestions ("quick fix") for
 Flymake diagnostics
Date: Thu, 27 Jun 2024 20:15:37 +0200

Hi Spencer,

Thanks for taking a look.

Spencer Baugh <sbaugh <at> janestreet.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> Date: Wed, 12 Jun 2024 10:43:14 +0200
>>> From:  Eshel Yaron via "Bug reports for GNU Emacs,
>>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>> 
>>> Following a recent short discussion[0] on emacs-devel, I'm opening this
>>> feature request so it doesn't get lost:
>>> 
>>> Flymake should provide a standard way for backends to associate fix
>>> suggestions with the diagnostics they produce, along with a
>>> backend-agnostic user interface (e.g. a command) for examining and
>>> applying such fixes.
>>> 
>>> I suggested a possible implementation that works quite well for me
>>> (with the three backends I've adapted so far - checkdoc, shellcheck
>>> and Eglot), but any other solution that gives various backends a
>>> standard way to provide their fixes would be just as welcome.

[...]

> I also think we have not sufficiently explored different UI
> possibilities, and I think adding to flymake now will limit us in what
> UI possibilities we can explore, no matter how generic we try to be.
> And that UI exploration can happen without adding to flymake.
>
> For example, maybe we want to have a command which can accept fixes
> output by a process running in M-x compile.  Baking the UI into flymake
> would make that impossible, wouldn't it?

I don't think adding a command for fixing the diagnostic at point should
preclude any other developments or explorations.  It's a useful thing to
have, and many Flymake backends have the needed data readily available.

> So before any change in flymake I would like to see much more
> exploration of "fix" UIs which are genuinely flymake-independent.

Flymake shows diagnostics, and "fixing" is what we do to diagnostics.
What would be the benefit of a Flymake-independent UI for fixing the
diagnostics that Flymake already shows?


Eshel

Previous Next

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