Re: Flymake refactored

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> enough of the details to be sure, but my gut feeling tells me that it'll
>> be hard to preserve the desirable properties while interfacing
>> through flymake (since it's targeted at a very different use case).

> I don't know (I also haven't looked at the code) but none of those
> things sound like showstoppers.  For a start, I'd be happy just
> preserving the fact that it isn't based on regexps.  The only thing a
> backend has to do is tell flymake where some problems exist. Even a naive
> solution like running nmxl in a subprocess emacs and prin1'int a list of
> collected errors, like we do for elisp-flymake-byte-compile now,
> shouldn't be horrible.

Oh, I don't forsee any major difficulty in writing an nxml backend for
flymake, *IF* we limit ourselves to the goal of making it work.  But if
we want it to work about as well as nxml-mode itself, it'll be harder.

>>> Didn't do this too.  If we mark it obsolete, what's the "use instead"
>>> message?
>> Don't know.  flymake-diagnostic-functions?
> Yeah, but right now that's saying "this bit is obsolete, go write a
> replacement and then use that instead. good luck "

I thought you were the one saying that flymake-proc is all legacy and
will be replaced.  I don't think anyone has claimed that flymake-proc is
*currently* obsolete, just that the plan is to retire it at some point
(this point being presumably after a replacement is written).

> Regarding the merge to emacs-26, do you see anything else we need to
> iron out before it?

Maybe just this issue of letting backends tell flymake.el whey they're
done (and letting flymake tell backends to abort the currently running
check)?


        Stefan