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

Previous Next

Full log

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71504 <at> debbugs.gnu.org, Eshel Yaron <me <at> eshelyaron.com>
Subject: Re: bug#71504: 30.0.50; FR: Fix suggestions ("quick fix") for
 Flymake diagnostics
Date: Thu, 27 Jun 2024 09:35:34 -0400

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.
>> 
>> 
>> Thanks and best regards,
>> 
>> Eshel
>> 
>> 
>> [0] https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg01137.html
>
> Spencer, any comments or suggestions?
>
> Thanks.

I basically agree with Joao's views in the linked thread.  It is already
possible to associate arbitrary data and actions with flymake
diagnostics by adding overlay properties, as Joao mentioned.

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?

So before any change in flymake I would like to see much more
exploration of "fix" UIs which are genuinely flymake-independent.  And
fit in well with existing Emacs functionality, rather than just porting
VSCode and LSP patterns.

Previous Next

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