[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flymake refactored

From: Stefan Monnier
Subject: Re: Flymake refactored
Date: Sun, 01 Oct 2017 23:12:49 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]