From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Flymake refactored Date: Sun, 08 Oct 2017 23:01:44 -0400 Message-ID: References: <87h8vmj3tr.fsf@lolita> <1507138648.1972.0@smtp.gmail.com> <874lre2von.fsf@gmail.com> <87mv566yjx.fsf@udel.edu> <87shex276r.fsf@gmail.com> <87efqh2sud.fsf@udel.edu> <877ew919hd.fsf@gmail.com> <87poa0z4ur.fsf@gmail.com> <83o9pjt6m8.fsf@gnu.org> <87376vxbqs.fsf@metapensiero.it> <87tvzavvbd.fsf@gmail.com> <87h8v9w6y3.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1507518118 1131 195.159.176.226 (9 Oct 2017 03:01:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Oct 2017 03:01:58 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: joaotavora@gmail.com (=?windows-1252?B?Sm/jbyBU4XZvcmE=?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 09 05:01:52 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e1OKF-0007Zj-CV for ged-emacs-devel@m.gmane.org; Mon, 09 Oct 2017 05:01:51 +0200 Original-Received: from localhost ([::1]:55836 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1OKL-0004nv-9h for ged-emacs-devel@m.gmane.org; Sun, 08 Oct 2017 23:01:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1OKD-0004m6-Qc for emacs-devel@gnu.org; Sun, 08 Oct 2017 23:01:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e1OKA-0003PD-PY for emacs-devel@gnu.org; Sun, 08 Oct 2017 23:01:49 -0400 Original-Received: from pmta11.teksavvy.com ([76.10.157.34]:33764) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1e1OKA-0003OS-Km for emacs-devel@gnu.org; Sun, 08 Oct 2017 23:01:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EgKQDh5dpZ/5+ESC1cHAEBBAEBCgEBg?= =?us-ascii?q?12BUokuhHmQA4F2mEGFRQKEIUMUAQIBAQEBAQEBA2gohRkBBAF5EAsNJxIUGIp?= =?us-ascii?q?sCKoHIgKLAQEBAQcCJoMtggKGZIRDhjUFoTWgMyiHF5cTNiKBDjIhCDKHZR0ki?= =?us-ascii?q?iABAQE?= X-IPAS-Result: =?us-ascii?q?A2EgKQDh5dpZ/5+ESC1cHAEBBAEBCgEBg12BUokuhHmQA4F?= =?us-ascii?q?2mEGFRQKEIUMUAQIBAQEBAQEBA2gohRkBBAF5EAsNJxIUGIpsCKoHIgKLAQEBA?= =?us-ascii?q?QcCJoMtggKGZIRDhjUFoTWgMyiHF5cTNiKBDjIhCDKHZR0kiiABAQE?= X-IronPort-AV: E=Sophos;i="5.42,498,1500955200"; d="scan'208";a="6048405" Original-Received: from unknown (HELO pastel.home) ([45.72.132.159]) by smtp.teksavvy.com with ESMTP; 08 Oct 2017 23:01:44 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 934E362DB0; Sun, 8 Oct 2017 23:01:44 -0400 (EDT) In-Reply-To: <87h8v9w6y3.fsf@gmail.com> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?= =?windows-1252?Q?ra=22's?= message of "Mon, 09 Oct 2017 00:33:40 +0100") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.34 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:219282 Archived-At: >> 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