Re: Flymake refactored

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

> [In the meantime I see you've been checking out emacs-diffs. Just a
> heads up that deleted the scratch/flymake-refactor and repushed it again
> with some different commits (but most of original tree is still
> identical hash-wise)
> Sorry for the git no-no. I did nothing special, just a bit obsessed with
> clean Git history I guess]

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

> Sorry, I mistook advice-add for add-function. I meant to say that
> cl-letf is better than advice-add for dynamic localized overrides, but
> you're right, it's not, as it binds the symbol globally. I fixed this.

I saw your recent introduction of proper hooks for checkdoc
and bytecomp.  I intend to take a closer look at them, but haven't had
time for it yet.

>> Let's try and move the ones that were sufficiently well designed that we
>> can keep using them in flymake.el without regret.  For the others, they
>> can definitely stay in flymake-proc.el.
> I can only think of porting flymake-proc-stop-all-syntax-checks, but:
> * That is hard to do generically (requires more API)
> * I don't see why it's particularly useful
> I'd rather fix bugs in flymake-proc.el like the one that leaves those
> @#$% *_flymake.c files behind (I think this happens because the cleanup
> functions are local to a buffer that is outlived by the process, BTW)

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

>> If we want to link something like nxml's checker into flymake in a good
>> way, we'll probably just need a completely different hook than
>> flymake-diagnostic-functions.
> Really? That's disappointing... Even with the new version of
> flymake-diagnostic-functions?

I don't actually know.  But since nxml's checker currently doesn't go
though flymake.el its design was special tailored to take advantage of
the info available in Emacs (e.g. knowledge of what was changed, to
avoid repeating previous checks, knowledge of what's displayed, so as
to do all the checks "instantly" yet lazily, ...).  I can't remember
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).

> Actually, I just (require 'flymake-proc) *after* (provide 'flymake) in
> flymake.el. It looks pretty clean to me, does you see any drawbacks?

Yes, I saw that.  It's indeed simple, and should work fine especially
for a file which we plan on marking obsolete.

>> I only meant to mark it as obsolete.  But if the whole of flymake-proc
>> is considered obsolete (or close enough), then it's not even worth it.
> Didn't do this too.  If we mark it obsolete, what's the "use instead"
> message?

Don't know.  flymake-diagnostic-functions?


        Stefan