Re: Adding fix suggestions to Flymake diagnostics

[Eshel Yaron]

João Távora <joaotavora@gmail.com> writes:

> I think this is the wrong way to approach it.  Refactorings can be, but are 
> not
> necessarily, associated with diagnostics.

Right, but this proposal is not about refactoring, rather it's about fix
suggestions for diagnosed issues :)

> [...]
> I just note that Flymake as a library is already flexible enough to
> make these context menu

Yes, Flymake lets backends associate arbitrary overlay properties with
diagnostics, but that requires backends to worry about UI stuff.  My
suggestion is to give backends a standard way to provide the relevant
data, and deal with the UI separately and consistently across backends.

> and I don't immediately see the need to bring new concepts such as
> "code edits" of a specific format into Flymake's API.  Just seems to
> increase coupling and brittleness.

That's a valid concern.  It would be nice to use a generic "code edit"
object/format that's not specific to Flymake.  Maybe we already have
something like that somewhere else in Emacs?

> [...]
> Maybe your refactor.el is promising (I had some unfinished version left around
> somewhere, too), but I don't see eglot.el requiring refactor.el, or expressing
> eglot-rename or eglot-code-actions in terms of refactor-rename or
> refactor-code-actions.

I only mentioned my refactor.el because I had refactor-apply-edits at
hand and it made it easier to demonstrate how fix suggestions can work,
I'm not suggesting to change anything about eglot-rename and friends.
FWIW, I use this refactor-rename both with (a modified) Eglot as the
backend instead of eglot-rename, as well as with other backends in modes
that don't have LSP support.  Similarly, with this fix suggestions
proposal, what I'd like to have is a consistent way of saying "fix this"
when presented with a diagnostic, regardless of whether I'm using LSP.


Best,

Eshel