Re: Adding fix suggestions to Flymake diagnostics

[João Távora]

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

> 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 don't think there's anything complex in Eglot's diagnostic-fixing UI that
can't be subsumed by any reasonable interface.

> 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?

What you're describing is similar, if not exactly identical to what
happens today

1. The overlay property you suggest exists.  It is 'keymap'
2. it's added to flymake diagnostics overlays via the diagnostic type property
   'flymake-overlay-control', part of Flymake's generic API for adding things
   to the overlay diagnostic.
3. The overlay _value_ is a simple keymap mapping the '[mouse-2]' binding to
   a function.  I think some users add more mappings to the keymap, which is
   bound to eglot-diagnostics-map.
4. The function is Eglot's.  It mixes UI and LSP logic, alas.
4.1 it expects the diagnostic at the mouse point to have a way to "produce"
    code edits (at first I thought this was async, but you're in luck: it's
    sync, which greatly simplified matters).
4.2 calls upon this logic to gather said edits
4.3 presents them to the user and applies them.  This is UI.

If you're suggesting to wrap all this setup in some function/macro of
newlibrary.el (the file name for your "new library") so that only the
complexity of 4.2 remains in eglot.el, then that's exactly what I'm
suggesting.

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.

But if it motivates you to start with a separate file, then newlibrary.el
(or whatever name you want to give it) is absolutely fine.

João