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

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

> On Tue, Aug 18, 2026, 17:51 Eshel Yaron <[email protected]> wrote:
>
>  > Well, I asked reasonably dumb llm to implement this, and it did pretty
>  > easily follow Flymake's manual and my little guide above to make a full
>  > 100loc backend with the aforemention correction capability.  See
>  > attached flymake-straightforward.el, it uses ripgrep to flag for the
>  > word "straight" and correct it to "str8".
>
>  Sure, it's doable, but it can be much easier, so backend authors like
>  Philip will actually provide the fixes they have readily available.
>  In your example, the infrastructure in my Flymake allows me to delete
>  half of the code in your flymake-straightforward.el and get basically
>  the same result.  
>
> If "your flymake", whatever it is, managed to shave 50 loc off a 100
> loc toy backend, that's not saying much for it, as a real backend will
> have many more to start with and those 50% quickly whittle down to
> irrelevance.

Dunno, flymake-harper isn't much longer.  IIRC there are quite a few
backends like that, which just feed some region to an external tool and
read back its output

But the point is not reducing loc: it's about (1) providing consistent,
backend-agnostic UI, which users can learn once and use without worrying
about which underlying backend they're interacting with; and (2) lifting
the burden of UI decisions from the shoulders of backend authors.

> It's of course trivial to define _a_ Flymake protocol for diagnostic quick fixes (a standard property
> that holds a string or an arbitrary transformation, for example, and a flymake-fix command and some
> more UI). Which is what I presume your code does. The pain is finding out such of the million possible
> protocols gives you the right convenience-to-flexibility ratio.

Sure, it's not a trivial task.  I just saying it's worth the effort,
since these fixes often make diagnostics much more useful.


Best,

Eshel