Re: Adding fix suggestions to Flymake diagnostics

[Eshel Yaron <me@eshelyaron.com>]

Hi João,

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

> On Sun, May 26, 2024 at 4:56 PM Eshel Yaron <me@eshelyaron.com> wrote:
>>
>> Yes, Flymake lets backends associate arbitrary overlay properties with
>> diagnostics, but that requires backends to worry about UI stuff.
>
> 100% Agree.  And indeed Eglot would like not to worry about UI, but it has
> to on more than one occasion.  So if you want to lift Eglot's diagnostic-fixing
> things out of there

That's not strictly my goal, although it could be a nice side effect.
What's important is to have a good, backend-agnostic, experience for
fixing diagnostics.  Such a standard UI may subsume some of Eglot's
bespoke UI, but it may also be complementary and the two can coexist,
perhaps with some LSP-specific use cases only provided by Eglot.

> , I suggest lifting them into another library that is *not* Flymake.
> That library would tend to be the new refactor.el, which would always
> need an "edit" concept of its own (with more or less similarities to
> LSP).

I don't think of fixing diagnostics as a form of refactoring, rather as
a separate activity/use case, even though there's some technical overlap
in that both involve applying edits to code.  You fix diagnosed issues
in response to their detection, while a refactor operation (rename,
extract, ...) is something you mostly do unprompted.  Therefore
refactor.el is not the best place to put something like my proposed
flymake-fix, IMO.  We could have a separate library, say flyfix.el, and
put the fix-diagnostics UI there.  We'd still need Flymake backends to
communicate with this new library, since these backends are best
positioned for providing fixes for the issues they diagnose, but this
communication can be transparent to Flymake--for example, it could rely
on some overlay property that backends would add to diagnostics and the
UI of the new library would look for.  If we really don't want to teach
Flymake about fixes, I think that could work.  WDYT?

> I gave your refactor.el a *very* cursory read but it seems to be at
> least more or less the length and complexity I envisioned such a
> library having.  It has its own concept of edit, seems to know how to
> present things as diffs, all good things.  The tricky part if I
> remember was how to talk to the backend about the kinds of actions
> available.

That's definitely a challenge.  Currently I tried to keep things pretty
flexible: there are standard operations (so far only "rename", but I'm
planning to add "extract", "inline", and "organize" for imports) and
custom operations.  Backends can say which operations they can
facilitate, and that can include both standard and custom operations.
For standard operations, the library (refactor.el) takes care of all the
UI consideration and the backend only needs to provide data in a
standard format, while for custom actions the library gives control back
to the backend.


Eshel