GNU bug report logs -
#71504
30.0.50; FR: Fix suggestions ("quick fix") for Flymake diagnostics
Previous Next
Full log
Message #17 received at 71504 <at> debbugs.gnu.org (full text, mbox):
> 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:
>
> > 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?
The benefit would be that we will be able to use that UI when "fixes"
are shown in, for example, the *compilation* buffer.
This bug report was last modified 326 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.