Re: Adding Flycheck to NonGNU ELPA

[Spencer Baugh]

Dmitry Gutov <dmitry@gutov.dev> writes:
> On 22/02/2024 12:14, Steve Purcell wrote:
>> 
>>> On 22 Feb 2024, at 03:16, Dmitry Gutov<dmitry@gutov.dev>  wrote:
>>>
>>> flymake-easy has another problem: IIUC it hasn't been updated for 10 years, 
>>> and as such only uses the obsolete Flymake protocol (one we keep in 
>>> flymake-proc.el for compatibility). It also employs defadvice.
>> The defadvice issue is easily fixed, but in general I can’t tell if
>> the package is defunct or would still be useful for people if it had
>> a refresh. I suspect the latter.
>
> I think there is demand for it, but code-wise, it might need a full rewrite.
>
> It also might make sense to contribute the improved helper to
> flymake.el directly, rather than have it as an external package - then
> the built-in modes could also use it.
>
> Because what I have to do at the moment, is copy ruby-flymake--helper
> with minor variations to use for each backend, and that's not ideal.
>
> Meanwhile the users of flymake-easy who target older versions of
> Flymake (including the current release) could continue to use the
> existing version, since the obsolete API is still supported (I think),
> just not quite recommended.

>From looking at ruby-flymake--helper, maybe it would be best to have a
new helper for working with processes.  It looks like
ruby-flymake--helper just wants to:

1. Send the current buffer text to a process.
2. When the process exits cleanly, call a callback with all the
process's output.

It seems like we could add a helper that supports that.  Then
ruby-flymake--helper would disappear in favor of some
process-run-and-call function.

Or... IMO, even better than a helper would be using Elisp threads for
this.  Then there's no need for any callback stuff.  Really, threads are
a natural fit for flymake, since flymake already provides a UI which can
display data computed asynchronously by threads, and that's IMO the
hardest part of using threads.