Re: [GNU ELPA] New package: flymake-harper

Hi João,

João Távora <[email protected]> writes:

>>> Philip Kaludercic <[email protected]> writes:
>
>>> [ This is related to a general missing feature in Flymake, which I've
>>>   requested in bug#71504: allowing backends to provide fixes for
>>>   diagnostics, which users can then apply/accept.  Without such support,
>>>   I'm not sure Flymake is the best fit for spell/grammar checking. ]
>> 
>>If any progress were to be made on that bug, I think it would totally
>>make sense to support this.
>
> Should be reasonably straightforward to do in flymake-harper.  Proceed
> exactly like eglot.el does.  AFAIR it is a strict user of Flymake's
> interfaces.
>
> - make Flymake error category symbols for harper diagnostics
> - when making diagnostics, add the correction meta-info (I presume it is
>   available) in the flymake-make-diagnostic call
> - use flymake-overlay-control on those category symbols.  Add a keymap,
> - make a new flymake-harper command and put it on the map.  The command
>   uses meta-info and does the correction
> - the map is activated when you click the flymake overlay
>
> If you want to autocorrect a number of diagnostics, make a command that
> uses flymake-diagnostics to get all diags in a region and iterate.

That's a viable solution for this particular backend, but in general
that's IMO way too much work for a backend, and it's still not enough:
you also need to choose keybindings, tell users about them, etc.  And
every backend needs to do all that separately.  That's not quite
"reasonably straightforward", sorry.
The only thing backends should worry about is providing the fix data;
the frontend should take care of all UI business.

I've probably mentioned that before, but indeed in my personal Flymake,
backends can (and do) provide fixes when creating a diagnostic, and as a
user I get to reuse the same command/keybinding to apply a fix,
regardless of which backend produced it.  So a standard API for fixes
has important benefits both for backend authors and for users.

> Alternatively, possibly just using harper-ls and/or multiplexing with
> any other language server you are using is also a decent idea that
> doesn't require a separate Flymake backend.

+1
For Harper specifically, that route works pretty well IME.


Eshel