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 13:44:22 +0300

> 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?

IOW, the "fixes" diagnostic shown by Flymake is not just diagnostic,
it's a suggestion to make some change in the source code.  So
supporting that cannot be separated from the more general concept of
making changes proposed by some external tool.  Or what am I missing?

Or maybe this is a simple misunderstanding: what do you mean by
"acting on diagnostic at point", and how could such an act be
indifferent to what and how is fixed?

Previous Next

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