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

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.

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. As it exists right now, Flymake errs on the side of the latter, as a
design principle, because going from rigid to flexible is much trickier. As
I happen to know from first-hand experience in backward-compatibly
retrofitting such trainwrecks as Imenu, ElDoc and Flymake itself.

Furthermore, I'd avoid being near-sighted. IME, which is almost 10 years
thinking about this stuff, so-called diagnostic "quick fixes" make up a
rather small subregion in a much wider context of buffer- and project-wide
refactoring support. Renames, extractions, scaffoldings, etc, are all
refactoring things that don't belong in Flymake at all, but nevertheless
should be grouped together with quick fixes in certain situations (such as
answering the question "how to improve things at point").

Once upon a time there was a reasonably serious effort to develop a proper
refactor.el here that was partially inspired by LSP and would provide a way
to do much of what its code actions do. The plan was obviously that Eglot
use it to link up LSP info and also allow a uniform refactor interface for
other languages, including native Elisp. The entry points would be similar
to Eglot's: some commands to run one or all actions, and some way to report
or suggest potential actions at point (including, but obviously not limited
to, diagnostic quick fixes). That effort struck the typical
analysis-paralysis iceberg here in this list and I have little motivation
to dig it up from the depths of the mud it has sunk into. As far as
Eglot/LSP is concerned, refactorings are great and well integrated into
Emacs already, even when multiple different servers are multiplexed
together.

Anyway, if such a refactor.el appears and allows Eglot to offload some or
lots or all of its refactoring code onto it, great. But I'm not holding my
breath.

João