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: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>
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 17:28:12 +0300

> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: sbaugh <at> janestreet.com,  71504 <at> debbugs.gnu.org
> Date: Sun, 07 Jul 2024 13:50:35 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> 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?

It sounds like we all agree, but then what is the problem?

Previous Next

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