Re: Adding fix suggestions to Flymake diagnostics

[João Távora]

On Mon, May 27, 2024 at 6:40 PM Eshel Yaron <me@eshelyaron.com> wrote:

> More or less, yes.  Except the overlay property wouldn't be keymap but
> something that just holds a function that produces the fix suggestion,

Overlays are for storing overlay known properties,  if you want to attach
arbitrary metadata to a diagnostic, I'd use the its `data` field.

> And again, I'm not especially interested in simplifying Eglot: that can
> be a nice bonus, but it's fine IMO if Eglot ends up keeping its code
> while also working with the standard API.

That's a shame, but your call. Eglot will have no more code to do the
same it already does.  I hope you've gotten my input of how I'd do it,
you're free to do it as you wish and I'm free to ignore it.

> > I just note that newlibrary.el _will_ have to know about
> > "edit-producing diagnostics", which means knowing about edits, or at
> > least a way to apply them.  It will likely have to require
> > 'refactor.el', which is where the "edit" format will live, and call on
> > it to present and eventually apply those edits.
> >
> > In fact, in my mind, newlibrary.el is so short that there's little
> > reason it shouldn't just be a small section of refactor.el.
>
> Right.  We also needs to know about Flymake diagnostics and their
> overlays, though, so the same argument suggests putting it in Flymake,
> as I did in my draft implementation :)

It's not a symmetrical situation.  It's quite different to use the
longstanding battle-tested, 4-major-version-old concept of "diagnostic"
in a new library and taiting a longstanding stable library with a
duplicated, brittle,  untested new concept that is completely foreign
to its genesis.