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