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

Previous Next

Full log

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

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: Re: bug#71504: 30.0.50; FR: Fix suggestions ("quick fix") for
 Flymake diagnostics
Date: Sun, 07 Jul 2024 10:53:12 +0200

Hi Eli,

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

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


Thanks,

Eshel

Previous Next

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