Re: Flymake refactored

[João Távora]

Stefan Monnier <address@hidden> writes:

>>> There's also a good argument to be made that flymake.el should itself work
>>> more lazily (don't start checking until the buffer is actually
>>> displayed, for example).
>> I like this one.  So flymake-mode either starts the check or does
>> something to window-configuration-change-hook?  Is that the idea?
> I hadn't thought about how to go about it, but indeed maybe
> window-configuration-change-hook could do the trick.

I think it does the trick nicely. I just pushed 11b37b4a9, please have a
look. Every `flymake-start' is deferred now to waiting until after the
current command is over (if that command exists) and until the buffer is
displayed (if it is not already). I think this is The Right Thing, as it
also takes care of editing and save operations in undisplayed buffers.

>> only works cooperatively, if all process creation uses it. If it is
>> optional, it's not worth it.
> There's also the issue that you end up checking all those many buffers
> (i.e. consuming CPU&RAM&battery during this time) without any guarantee
> that we'll actually look at those buffers.

This is an orthogonal bit taken care by the above fix. I agree it mostly
render this throttling sophistication useless.