From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used Date: Tue, 28 Oct 2014 21:26:24 +0200 Message-ID: <831tps2dy7.fsf@gnu.org> References: <87a94h2tpf.fsf@engster.org> <838uk02i9j.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1414524445 19553 80.91.229.3 (28 Oct 2014 19:27:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Oct 2014 19:27:25 +0000 (UTC) Cc: 18856@debbugs.gnu.org, deng@randomsample.de To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 28 20:27:19 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XjCQH-0004uX-EX for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Oct 2014 20:27:17 +0100 Original-Received: from localhost ([::1]:41136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjCQG-0001nS-OZ for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Oct 2014 15:27:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38520) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjCQ7-0001gp-ER for bug-gnu-emacs@gnu.org; Tue, 28 Oct 2014 15:27:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XjCQ2-0006wp-JP for bug-gnu-emacs@gnu.org; Tue, 28 Oct 2014 15:27:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45930) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjCQ2-0006wQ-GH for bug-gnu-emacs@gnu.org; Tue, 28 Oct 2014 15:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XjCQ1-00051P-MG for bug-gnu-emacs@gnu.org; Tue, 28 Oct 2014 15:27:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Oct 2014 19:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18856 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18856-submit@debbugs.gnu.org id=B18856.141452440219271 (code B ref 18856); Tue, 28 Oct 2014 19:27:01 +0000 Original-Received: (at 18856) by debbugs.gnu.org; 28 Oct 2014 19:26:42 +0000 Original-Received: from localhost ([127.0.0.1]:38028 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjCPh-00050k-5W for submit@debbugs.gnu.org; Tue, 28 Oct 2014 15:26:41 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:35898) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjCPd-00050V-LU for 18856@debbugs.gnu.org; Tue, 28 Oct 2014 15:26:39 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NE6002005Q8FR00@mtaout29.012.net.il> for 18856@debbugs.gnu.org; Tue, 28 Oct 2014 21:25:11 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NE600PVF5XY4T20@mtaout29.012.net.il>; Tue, 28 Oct 2014 21:25:10 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:95219 > From: Stefan Monnier > Cc: deng@randomsample.de, 18856@debbugs.gnu.org > Date: Tue, 28 Oct 2014 15:01:46 -0400 > > >> IOW jit-lock-defer should use a non-idle timer for this case. > > But then how do we ensure the fontifications don't happen for as long > > as Emacs isn't idle? > > Yes, that question did occur to me as well, but I didn't have an > immediate answer, so I decided to stay silent ;-) > > > test idleness by hand inside the timer function? > > I don't think we can really do that unless we can access the "time since > idleness started" rather than just whether Emacs is idle or not (which > it almost always is when running timer functions). Doesn't current-idle-time fit the bill? > >> Note that an alternative implementation of jit-lock-defer which only > >> defers when there is not input pending would supposedly not suffer from > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > You mean, when there _is_ input pending, right? > > Of course, thanks for correcting me. > > >> this problem since it wouldn't defer fontification in this case (of > >> course, that would suffer from the reverse problem that by failing to > >> defer fontification, the redisplay may not be able to keep up with > >> process output). > > Indeed, so what's the point of doing that? > > To only defer fontification when we know "for sure" that the user is > waiting for further processing. Sorry, you lost me. When input is pending, what further processing is the user waiting for? And anyway, isn't running off an idle timer already an attempt to defer when there's more input, i.e. Emacs is not idle? > If jit-lock-defer-time is smaller than the normal time between key > presses, deferring fontification actually increases the amount of > work done by Emacs, since we end up doing 2 redisplays per command > (once without fontification, plus another one with fontification > after jit-lock-defer-time passed), so for "normal" use, it's more > efficient not to defer. I don't think this is too high a price. First, as Alain established, what takes 90% of the time is not redisplay, but fontifications, and those are run only once. And second, the 2nd redisplay will only redraw the portions that were fontified, not the entire window. So this is not "twice", but more like 1.2 times. > BTW, another reason not to defer for process-output is that contrary to > key-commands, process-output is processed more efficiently if we receive > it in large chunks than in small chunks. So if there's "pending process > output", it's OK to keep redisplaying with fontification, since it just > means that the next time we get to read the process output we'll get more > output, which we'll hence process more efficiently. Yes, I actually thought of disabling deferral when a process filter runs.