Re: Flymake refactored

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

>> The problem can be fixed "anywhere" between desktop.el and make-process.
>> There's a good argument that desktop.el should load buffers more lazily.
> Would be hard to predict how lazy it has to be fix these issues.

The same kind of issues appears with large desktop sessions w.r.t other
features than flymake.  We had a discussion here some months ago
(year(s)?) about having desktop create "uninitialized buffers" which
only finish their initialization when they get displayed.

So it would behave a bit like what happens with previously "saved tabs"
when you restart Firefox.

>> 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 asking backends to perform the throttling is a bad idea: we want
>> the backends to be as lean/simple/concise as possible.
> If they used the make-process helper, they would keep these
> qualities. But on second thought the whole idea behind throttling
> (make-process or backend) seems too feeble to be worth the effort. It
> 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.


        Stefan