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

Previous Next

Full log

View this message in rfc822 format

From: Eshel Yaron <me <at> eshelyaron.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, 71504 <at> debbugs.gnu.org
Subject: bug#71504: 30.0.50; FR: Fix suggestions ("quick fix") for Flymake diagnostics
Date: Sun, 07 Jul 2024 13:50:35 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eshel Yaron <me <at> eshelyaron.com>
>> Cc: sbaugh <at> janestreet.com,  71504 <at> debbugs.gnu.org
>> Date: Sun, 07 Jul 2024 10:53:12 +0200
>> 
>> >> From: Eshel Yaron <me <at> eshelyaron.com>
>> >> Cc: Eli Zaretskii <eliz <at> gnu.org>,  71504 <at> debbugs.gnu.org
>> >> Date: Thu, 27 Jun 2024 20:15:37 +0200
>> >> 
>> >> Spencer Baugh <sbaugh <at> janestreet.com> writes:
>> >>
>> >> > 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?
>> >
>> > The benefit would be that we will be able to use that UI when "fixes"
>> > are shown in, for example, the *compilation* buffer.
>> 
>> It'd be good to enhance compilation buffers as well, but this feature
>> request is about interaction with Flymake diagnostics, that are shown in
>> the diagnosed buffer: I'd like to have a standard way to act on (fix)
>> the diagnostic at point.
>
> I frankly don't understand what you are saying here.  Several people
> opined that we should take a broader view on the fixes and how to
> handle them, but you insist that Flymake should have its own solution?

No.  I only insist that there should be a command for fixing the
Flymake diagnostic at point.  If it's part of a "broader solution",
that's swell.

> IOW, the "fixes" diagnostic shown by Flymake is not just diagnostic,
> it's a suggestion to make some change in the source code.

I think there is a misunderstanding here: it's not about specific
diagnostics which represent fixes, this is about enriching
(potentially) all diagnostics with backend-provided fix suggestions,
and adding a command that applies such fixes.  For example, with my
implementation I use the same command for fixing checkdoc, shellcheck
and LSP diagnostics.

> So supporting that cannot be separated from the more general concept
> of making changes proposed by some external tool.  Or what am I
> missing?

IIUC, I think I agree.  In my implementation, Flymake delegates the
application of the code changes to another library, that includes a
general purpose function for applying code changes.

> Or maybe this is a simple misunderstanding: what do you mean by
> "acting on diagnostic at point"

Applying a suggested code change that resolves the diagnostic.

> , and how could such an act be indifferent to what and how is fixed?

A single command should let you fix diagnostics from different sources
(backends).  It doesn't need to be indifferent, just consistent.

Does that make sense?

Previous Next

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