[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, 09 Oct 2017 11:19:57 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux)

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.

reply via email to

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