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

[Spencer Baugh <sbaugh@janestreet.com>]

Eshel Yaron <me@eshelyaron.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Eshel Yaron <me@eshelyaron.com>
>>> Cc: sbaugh@janestreet.com,  71504@debbugs.gnu.org
>>> Date: Thu, 11 Jul 2024 07:43:53 +0200
>>> 
>>> Hi Eli,
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> > It sounds like we all agree, but then what is the problem?
>>> 
>>> I'm not sure I understand what you're asking, I don't think there's any
>>> problem here per se, just a need for a decision on how to proceed:
>>> 
>>> If you and Spencer agree with my overall implementation, I'll polish it
>>> a bit and post an updated patch for master.  If you want to implement
>>> the requested feature in some other way, that's perfectly fine too.
>>> Lastly, if you don't think Emacs should provide a command for applying
>>> fixes to Flymake diagnostics, feel free to close this feature request.
>>
>> I'm asking what is the overall idea of the proposed implementation.  I
>> think it's worthwhile to present it, so we could see if we all agree
>> with that idea and the details of the proposed implementation.
>
> Thanks.  To clarify, ideally Spencer will implement this feature request
> however he sees fit.  I'm offering my implementation as a reference, but
> I'm not advocating for it over other alternatives that may come up.
>
> The idea of my implementation is to allow Flymake backends to associate
> fixes with some of the diagnostics they create, and to add a command
> that tries to apply a fix for the diagnostic at point.  For the details,
> see below the same patch I attached to this message:
> https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg01318.html

A few issues:

- At an immediate glance, fix-function should return a cl-defstruct
instead of a list, to match the rest of the flymake API.

- An implementation of this feature in flymake absolutely must come with
support for Eglot, as the main user of this feature.  Which, if the
Eglot maintainer doesn't want to merge that, may mean we can't move
forward.

- Your patch adds support in shellcheck for fixes.  That's
uncontroversially useful and good.  Could we add this support in a
shellcheck-specific way before finalizing the flymake fix API?  (Taking
care to add it in a way that can be supported by a later unified UI, of
course)

- Likewise, you mentioned adding support for fixes to checkdoc, although
I'm not sure where that patch is.  That sounds also extremely useful,
could it also be added first?

- Do you hope to have a default binding for the fix-applying command you
mention?  Certainly I would like that, and I think it's worth talking
about now.

More broadly, I'm still a bit unsure about this whole approach.

- What UI, exactly, do you want to build on top of this?  Can we see an
example of this UI?  Or is it really just this one command?

- If it's just the one command, and your hope is to give this some
default binding, what exactly is the problem with doing that via a
keymap overlay as Joao suggests?  What do you want to do which can't be
done with a keymap overlay bound to a backend-specific function?

- Could this UI also support spell-checking, via ispell or flyspell?  It
seems like "fix the spelling of a typo'd word" is something that would
very naturally fit this whole idea.

- Could we implement all this outside of flymake, I wonder, with some
kind of refactor-backend-functions buffer-local?