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

Eshel Yaron <[email protected]> writes:

> Dunno, flymake-harper isn't much longer.

Then again, your claim of "halving the line count" is probably a bit
exagerated.  The diagnostic category and overlay set up boilerplate is
about 25 lines, and half of it is that "mouse-call" generic util.

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

As I said, you can skin that cat multiple ways.  One of them is adding
some helpers to both reduce boilerplate and ease adhesion to convention.
A helper to make the overlay button keymap and a generic "mouse-call"
util would lick most of the verbosity.  But even if you don't do that,
my main goal is to dispel a falsehood: it is pretty straightforward, if
somewhat verbose, to get quick-fix functionality for any Flymake
backend: no hacks or meddling with Flymake internals needed.

>> 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
>> [which] 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.

It's not trivial indeed (else it would have been made, probably) and the
most worrysome part is that you don't seem to have understood it doesn't
start in Flymake at all.

João