From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier 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 15:01:46 -0400 Message-ID: References: <87a94h2tpf.fsf@engster.org> <838uk02i9j.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1414523012 27592 80.91.229.3 (28 Oct 2014 19:03:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Oct 2014 19:03:32 +0000 (UTC) Cc: 18856@debbugs.gnu.org, deng@randomsample.de To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 28 20:03:24 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 1XjC39-0006db-Q8 for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Oct 2014 20:03:23 +0100 Original-Received: from localhost ([::1]:41061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjC39-0003PS-4h for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Oct 2014 15:03:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjC2x-0003P8-FQ for bug-gnu-emacs@gnu.org; Tue, 28 Oct 2014 15:03:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XjC2p-0007Xu-7N for bug-gnu-emacs@gnu.org; Tue, 28 Oct 2014 15:03:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45926) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjC2p-0007Xf-3C for bug-gnu-emacs@gnu.org; Tue, 28 Oct 2014 15:03:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XjC2o-0004Pc-JT for bug-gnu-emacs@gnu.org; Tue, 28 Oct 2014 15:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Oct 2014 19:03:02 +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.141452293816890 (code B ref 18856); Tue, 28 Oct 2014 19:03:02 +0000 Original-Received: (at 18856) by debbugs.gnu.org; 28 Oct 2014 19:02:18 +0000 Original-Received: from localhost ([127.0.0.1]:38023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjC25-0004OL-Re for submit@debbugs.gnu.org; Tue, 28 Oct 2014 15:02:18 -0400 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]:40563) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjC1y-0004O7-Q3 for 18856@debbugs.gnu.org; Tue, 28 Oct 2014 15:02:15 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id AD2B584F9D; Tue, 28 Oct 2014 15:02:09 -0400 (EDT) Original-Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 866D41E5874; Tue, 28 Oct 2014 15:01:46 -0400 (EDT) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 63360B418B; Tue, 28 Oct 2014 15:01:46 -0400 (EDT) In-Reply-To: <838uk02i9j.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 28 Oct 2014 19:53:12 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.71, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TRANSFR 0.11, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca 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:95218 >> 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). Another approach would be to cancel that timer from pre-command-hook. >> 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. 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. 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. Stefan