Re: Flymake refactored

[João Távora]

Stefan Monnier <address@hidden> writes:

>> However, I have a problem when using the new implementation in my real
>> development context, that wasn't present before (before João work I was using
>> python-flymake-pyflakes from ELPA).
>
>> I use the `desktop' functionality, to keep a persistent state of open files,
>> and in one project the `emacs.desktop' file has 367 entries, of which 284 are
>> python-mode buffers: now when I open that project the python-flymake backend
>> gets disabled with the following errors, for each python-mode buffer:
>
>>   Warning [flymake xxx.py]: Disabling backend python-flymake because
>> (file-error Creating pipe Troppi file aperti)
>
> IIUC this problem is with some "old" backend that worked fine with the
> old flymake but now exhibits a poor behavior with the new flymake.
> In that case I suggest you `M-x report-emacs-bug` so we can track
> it down.

A seemingly good workaround to fix this is to bind
flymake-start-syntax-check-on-find-file to nil around that mega
file-finding operation. This is a bit what Eli suggested, I think.

And I think the only real reason "old" Flymake managed to launch ~300
processes immediately without choking up is that it did so under
with-demoted-errors, so that's not really a fair comparison (though,
granted, I removed it --- and now I understand why it was there).

> It's probably due to changes in the way flymake decides when to run
> the backend(s) and we should fix those issues.

I don't see what flymake.el can do about it, since it is was designed to
be agnostic to the way backends allocate resources to start syntax
checks.

In other words, to "properly" fix this, the Python backend must throttle
its process-making, which is another argument in favor of using a more
sophisticated version of the 'flymake-easy-make-process' function that I
sent you some a couple of days ago.

Another way to fix it is to add throttling capabilities to make-process
itself.  I don't know if it is possible since it is a big change to its
semantics, which seem to imply that system resources are immediately
allocated. Meaning that if a :throttle arg were accepted

   (process-id (make-process :name "true" :command '("true") :throttle t))

wouldn't make sense, because make-process could actually not have
allocated any system resources.