Eli Zaretskii writes: >> From: Stefan Monnier >> Date: Sat, 07 Oct 2017 09:28:04 -0400 >> >> > Yes, that is the natural way. But should it go into the emacs-26 branch? >> >> I'll let Eli&John decide. > > If it's just a Flymake back-end, and doesn't affect anything else > unless activated, I see no reason not to have it on the release > branch, assuming that its support in the version of Flymake on the > release branch is reasonably good. Great, I'll do my best to get there: current version of python-flymake, ameliorated with Noam's suggestions, works pretty well, and I'm right now trying it with customized settings so that it uses an alternative checker (flake8). 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) Warning [flymake xxx.py]: Disabling backend flymake-proc-legacy-flymake because (error Can find a suitable init function) where "Troppi file aperti" means "Too many open files". The mode-line of all those buffers tells that Flymake is in "Wait" status. I wonder if the problem is in the backend or rather in the new Flymake mechanism. Also, I will try to understand whether there could be a way to tell Flymake to run the checker only after the buffer has been modified, in other words to *not* run it on newly open files. Any hint on how to investigate the issue? I'm attaching below the current backend I'm trying out. Thanks&bye, lele.