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

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

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

[Eli Zaretskii]

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

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

[Spencer Baugh]

Eli Zaretskii <eliz@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@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.

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

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi Spencer,

Thanks for taking a look.

Spencer Baugh <sbaugh@janestreet.com> writes:

> Eli Zaretskii <eliz@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@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?


Eshel