Re: Missing support for Flymake fix suggestions

[Spencer Baugh]

Eshel Yaron <me@eshelyaron.com> writes:
> Hi Philip,
>
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Eshel Yaron <me@eshelyaron.com> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Michael Kirkland via "Emacs development discussions."
>>>> <emacs-devel@gnu.org> writes:
>>>>
>>>>> I created a Clippy back-end for flymake. Clippy is the main Rust linter.
>>>>>
>>>>> In short, this package overlays Rust code with suggestions produced by 
>>>>> Clippy, the Rust linter.
>>>>>
>>>>> The code can be found here - https://github.com/SiberzK/clippy-flymake.
>>>
>>> Looks like this Flymake backend is able to suggest fixes for some of the
>>> issues it detects, like many other backends.  It's a shame that Flymake
>>> still does not facilitate applying such fix suggestions, so backends
>>> resort to spelling out the suggestion in a help string.  :(
>>>
>>> Can we make some progress with bug#71504, to improve this situation?
>
>> Can you briefly summarise the status of that bug report?
>
> My initial message in that feature request gives a short summary which
> remains current.  Here's the gist of it:
>
>   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.
>
> The status hasn't changed AFAICT, we're waiting for Spencer to find some
> time to implement this feature or green-light my proposed implementation.

I gave some feedback on the implementation before.  Could you send or
link the latest version?

- Please start representing fixes with a cl-defstruct.

- Please land the shellcheck fix support first and independently,
  because it's useful as a separate command which doesn't depend on this
  new API.

- Support for Eglot in the initial version is a requirement for me.
  Even if an implementation seems good to me, I don't want to install it
  unless we're also using it in Eglot at the same time.  Otherwise we
  will be causing substantial UI fragmentation which will be confusing
  to users.

Thank you for working on this.  I do think it's probably a good idea to
support fixes explicitly in flymake, in a way that can support a
pluggable UI.