[Top][All Lists]

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

Re: Flymake refactored

From: João Távora
Subject: Re: Flymake refactored
Date: Mon, 02 Oct 2017 02:01:19 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

> That's OK.  We want to allow this in scratch branches.

Yeah, but boy does it spam emacs-diffs. Can we enable push -f in just
the scratch branches. I don't know if its possible but Google says it's
a pretty commonly requested feature.

> "Hard to do generically + not particularly useful" qualifies as
> "with regret" I think ;-)

Au contraire, with delight, it's not everyday that a hard thing to do is
useless :-)

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

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

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


reply via email to

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