From unknown Fri Sep 05 11:01:08 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#18856 <18856@debbugs.gnu.org> To: bug#18856 <18856@debbugs.gnu.org> Subject: Status: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used Reply-To: bug#18856 <18856@debbugs.gnu.org> Date: Fri, 05 Sep 2025 18:01:08 +0000 retitle 18856 24.4; *grep* output buffer not getting fontified when jit-loc= k-defer-time is used reassign 18856 emacs submitter 18856 David Engster severity 18856 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 27 15:34:19 2014 Received: (at submit) by debbugs.gnu.org; 27 Oct 2014 19:34:19 +0000 Received: from localhost ([127.0.0.1]:36971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xiq3X-0002v0-0s for submit@debbugs.gnu.org; Mon, 27 Oct 2014 15:34:19 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55540) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xiq3U-0002un-EP for submit@debbugs.gnu.org; Mon, 27 Oct 2014 15:34:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xiq3I-0003ON-4y for submit@debbugs.gnu.org; Mon, 27 Oct 2014 15:34:11 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:33090) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xiq3I-0003OJ-0o for submit@debbugs.gnu.org; Mon, 27 Oct 2014 15:34:04 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xiq3B-0005GM-Qj for bug-gnu-emacs@gnu.org; Mon, 27 Oct 2014 15:34:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xiq35-0003L4-PR for bug-gnu-emacs@gnu.org; Mon, 27 Oct 2014 15:33:57 -0400 Received: from randomsample.de ([5.45.97.173]:43338) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xiq35-0003Km-BJ for bug-gnu-emacs@gnu.org; Mon, 27 Oct 2014 15:33:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=KigYBR/7UlKqR/ix74FDCoGm0HcaUmxd9WnM3KMghIY=; b=KbYODS6ZMAIhEZ0Qa1/Oa6x4xgL5nr+Kxp+FeLz5OuvdjWCvsMKo1J/ypp4QOv4NoIjP+QOX2pf2VjzQSg9XK4S1eHbfboP8ZOeEUhzPwfUM3SK1IDhrzrayAExs+vtV; Received: from dslc-082-083-054-062.pools.arcor-ip.net ([82.83.54.62] helo=spaten) by randomsample.de with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xiq34-0003Kx-6j for bug-gnu-emacs@gnu.org; Mon, 27 Oct 2014 20:33:50 +0100 From: David Engster To: bug-gnu-emacs@gnu.org Subject: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used Date: Mon, 27 Oct 2014 20:33:48 +0100 Message-ID: <87a94h2tpf.fsf@engster.org> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.9 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Recipe: * emacs -Q * M-x set-variable RET jit-lock-defer-time RET 0.05 RET * Call M-x rgrep and search for some string in some directory You should be able to see that the *grep* buffer capturing grep's output is not getting fontified until you hit a key. I would expect that it gets fontified automatically when new output arrives. Note that the same problem happens for other buffers which capture process output, like compilation buffers. -David From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 28 12:37:16 2014 Received: (at 18856) by debbugs.gnu.org; 28 Oct 2014 16:37:16 +0000 Received: from localhost ([127.0.0.1]:37926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xj9lj-0000id-53 for submit@debbugs.gnu.org; Tue, 28 Oct 2014 12:37:15 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:58310) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xj9le-0000hY-S7 for 18856@debbugs.gnu.org; Tue, 28 Oct 2014 12:37:12 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NE500H00XU1UL00@mtaout29.012.net.il> for 18856@debbugs.gnu.org; Tue, 28 Oct 2014 18:35:43 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NE500FOIY3J9130@mtaout29.012.net.il>; Tue, 28 Oct 2014 18:35:43 +0200 (IST) Date: Tue, 28 Oct 2014 18:36:56 +0200 From: Eli Zaretskii Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used In-reply-to: <87a94h2tpf.fsf@engster.org> X-012-Sender: halo1@inter.net.il To: David Engster Message-id: <83fve82lsn.fsf@gnu.org> References: <87a94h2tpf.fsf@engster.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18856 Cc: 18856@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: David Engster > Date: Mon, 27 Oct 2014 20:33:48 +0100 > > Recipe: > > * emacs -Q > > * M-x set-variable RET jit-lock-defer-time RET 0.05 RET > > * Call M-x rgrep and search for some string in some directory > > You should be able to see that the *grep* buffer capturing grep's output > is not getting fontified until you hit a key. I would expect that it > gets fontified automatically when new output arrives. First, my crystal ball says you omitted something from this recipe, because if I strictly follow these steps, I cannot even see the matches produced by Grep, because the shell command inserted by rgrep into the *grep* buffer is longer than the visible portion of the window displaying the buffer. Moreover, rgrep doesn't seem to obey grep-scroll-output (which will soon be a separate bug report), so you cannot see the output. Nevertheless, the problem does exist. I used the following recipe to reproduce it: emacs -Q M-x set-variable RET jit-lock-defer-time RET 0.05 RET M-: (setq-default grep-scroll-output t) RET M-x grep RET RET Here's what I saw while digging into this problem: . It looks like the idleness state is not reset when we receive input from a subprocess. At least, what I see is that jit-lock-deferred-fontify is called only once, prior to any input is received from Grep, and never called again, until you press a key or send some other input event Emacs's way. I can overcome this problem if I add a call to internal-timer-start-idle at the end of compilation-handle-exit. Not sure this is TRT, though. If not, what else? . But even after the call to internal-timer-start-idle is made when Grep exits, and jit-lock-deferred-fontify _is_ called, there's no fontification. Why? because input-pending-p, called by sit-for, returns non-nil, and we don't call redisplay. This happens to me on MS-Windows in a GUI session only. If I put a breakpoint in readable_events, here: static bool readable_events (int flags) { if (flags & READABLE_EVENTS_DO_TIMERS_NOW) timer_check (); /* If the buffer contains only FOCUS_IN_EVENT events, and READABLE_EVENTS_FILTER_EVENTS is set, report it as empty. */ if (kbd_fetch_ptr != kbd_store_ptr) { if (flags & (READABLE_EVENTS_FILTER_EVENTS #ifdef USE_TOOLKIT_SCROLL_BARS | READABLE_EVENTS_IGNORE_SQUEEZABLES #endif )) { struct input_event *event; event = ((kbd_fetch_ptr < kbd_buffer + KBD_BUFFER_SIZE) ? kbd_fetch_ptr : kbd_buffer); do { if (!( <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< #ifdef USE_TOOLKIT_SCROLL_BARS (flags & READABLE_EVENTS_FILTER_EVENTS) && #endif event->kind == FOCUS_IN_EVENT) #ifdef USE_TOOLKIT_SCROLL_BARS && !((flags & READABLE_EVENTS_IGNORE_SQUEEZABLES) && (event->kind == SCROLL_BAR_CLICK_EVENT || event->kind == HORIZONTAL_SCROLL_BAR_CLICK_EVENT) && event->part == scroll_bar_handle && event->modifiers == 0) #endif ) return 1; event++; then I see a single event, BUFFER_SWITCH_EVENT, being reported. Should input-pending-p ignore such events? Finally, if I disable blink-cursor-mode, the problem with input-pending-p doesn't happen, and the only change that is needed to fix this is a call to internal-timer-start-idle mentioned above. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 28 13:09:31 2014 Received: (at 18856) by debbugs.gnu.org; 28 Oct 2014 17:09:31 +0000 Received: from localhost ([127.0.0.1]:37967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjAGw-0001YW-Rl for submit@debbugs.gnu.org; Tue, 28 Oct 2014 13:09:31 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:38591) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjAGu-0001YO-CO for 18856@debbugs.gnu.org; Tue, 28 Oct 2014 13:09:28 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 219CD84F43; Tue, 28 Oct 2014 13:09:28 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 7A13E1E5B8C; Tue, 28 Oct 2014 13:09:02 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 5B275B4245; Tue, 28 Oct 2014 13:09:02 -0400 (EDT) From: Stefan Monnier To: David Engster Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used Message-ID: References: <87a94h2tpf.fsf@engster.org> Date: Tue, 28 Oct 2014 13:09:02 -0400 In-Reply-To: <87a94h2tpf.fsf@engster.org> (David Engster's message of "Mon, 27 Oct 2014 20:33:48 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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-Spam-Status: No X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 18856 Cc: 18856@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.9 (--) > You should be able to see that the *grep* buffer capturing grep's output > is not getting fontified until you hit a key. I would expect that it > gets fontified automatically when new output arrives. That's probably because the jit-lock-defer defers fontification to an idle-timer, but process output is not considered as "activity" so the idle timers aren't re-run after process output is received. IOW jit-lock-defer should use a non-idle timer for this case. Note that an alternative implementation of jit-lock-defer which only defers when there is not input pending would supposedly not suffer from 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). Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 28 13:39:08 2014 Received: (at 18856) by debbugs.gnu.org; 28 Oct 2014 17:39:08 +0000 Received: from localhost ([127.0.0.1]:37999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjAjb-0002Ip-Fj for submit@debbugs.gnu.org; Tue, 28 Oct 2014 13:39:07 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:50607) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjAjZ-0002If-Me for 18856@debbugs.gnu.org; Tue, 28 Oct 2014 13:39:06 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id D4CDE84FCC; Tue, 28 Oct 2014 13:39:04 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 3A4241E5874; Tue, 28 Oct 2014 13:38:36 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 15F04B4245; Tue, 28 Oct 2014 13:38:36 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used Message-ID: References: <87a94h2tpf.fsf@engster.org> <83fve82lsn.fsf@gnu.org> Date: Tue, 28 Oct 2014 13:38:36 -0400 In-Reply-To: <83fve82lsn.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 28 Oct 2014 18:36:56 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 18856 Cc: 18856@debbugs.gnu.org, David Engster X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.9 (--) > I can overcome this problem if I add a call to > internal-timer-start-idle at the end of compilation-handle-exit. > Not sure this is TRT, though. I don't think this is right: as mentioned the issue is not specific to compilation, so we'd really need to call internal-timer-start-idle from the code that runs process-filters. And it implies a different definition of "idle" than the one we've had so far, so it'd be an incompatible change. > then I see a single event, BUFFER_SWITCH_EVENT, being reported. > Should input-pending-p ignore such events? I think so, yes, because these events are not (consciously) generated by the user. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 28 13:53:32 2014 Received: (at 18856) by debbugs.gnu.org; 28 Oct 2014 17:53:32 +0000 Received: from localhost ([127.0.0.1]:38003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjAxW-0002e6-Df for submit@debbugs.gnu.org; Tue, 28 Oct 2014 13:53:31 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:58477) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjAxS-0002db-CC for 18856@debbugs.gnu.org; Tue, 28 Oct 2014 13:53:28 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NE600H0018R8200@a-mtaout21.012.net.il> for 18856@debbugs.gnu.org; Tue, 28 Oct 2014 19:53:19 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NE600H2V1OV6G50@a-mtaout21.012.net.il>; Tue, 28 Oct 2014 19:53:19 +0200 (IST) Date: Tue, 28 Oct 2014 19:53:12 +0200 From: Eli Zaretskii Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <838uk02i9j.fsf@gnu.org> References: <87a94h2tpf.fsf@engster.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18856 Cc: 18856@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Date: Tue, 28 Oct 2014 13:09:02 -0400 > Cc: 18856@debbugs.gnu.org > > 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? test idleness by hand inside the timer function? > 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? > 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? From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 28 15:02:18 2014 Received: (at 18856) by debbugs.gnu.org; 28 Oct 2014 19:02:18 +0000 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 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 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) 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) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 63360B418B; Tue, 28 Oct 2014 15:01:46 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used Message-ID: References: <87a94h2tpf.fsf@engster.org> <838uk02i9j.fsf@gnu.org> Date: Tue, 28 Oct 2014 15:01:46 -0400 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) MIME-Version: 1.0 Content-Type: text/plain 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-Spam-Status: No X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 18856 Cc: 18856@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.9 (--) >> 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 28 15:26:41 2014 Received: (at 18856) by debbugs.gnu.org; 28 Oct 2014 19:26:42 +0000 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 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 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) 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) Date: Tue, 28 Oct 2014 21:26:24 +0200 From: Eli Zaretskii Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <831tps2dy7.fsf@gnu.org> References: <87a94h2tpf.fsf@engster.org> <838uk02i9j.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18856 Cc: 18856@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 29 00:06:24 2014 Received: (at 18856) by debbugs.gnu.org; 29 Oct 2014 04:06:24 +0000 Received: from localhost ([127.0.0.1]:38196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjKWd-00013U-Cp for submit@debbugs.gnu.org; Wed, 29 Oct 2014 00:06:23 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:45605) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjKWb-00013E-3t for 18856@debbugs.gnu.org; Wed, 29 Oct 2014 00:06:21 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0IAOatTlRFpY87/2dsb2JhbABcgw6DYtJRBAICgRwXAQF8hAMBAQMBViMFCws0EhQYDSSISwnLcgEBAQEGAQEBAR6RCAeESwWyIIFvgjSBYCGCegEBAQ X-IPAS-Result: Aq0IAOatTlRFpY87/2dsb2JhbABcgw6DYtJRBAICgRwXAQF8hAMBAQMBViMFCws0EhQYDSSISwnLcgEBAQEGAQEBAR6RCAeESwWyIIFvgjSBYCGCegEBAQ X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="95480502" Received: from 69-165-143-59.dsl.teksavvy.com (HELO pastel.home) ([69.165.143.59]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Oct 2014 00:06:15 -0400 Received: by pastel.home (Postfix, from userid 20848) id E78908592; Wed, 29 Oct 2014 00:06:14 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used Message-ID: References: <87a94h2tpf.fsf@engster.org> <838uk02i9j.fsf@gnu.org> <831tps2dy7.fsf@gnu.org> Date: Wed, 29 Oct 2014 00:06:14 -0400 In-Reply-To: <831tps2dy7.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 28 Oct 2014 21:26:24 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 18856 Cc: 18856@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> 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? The user is waiting for Emacs to process the input that he's already sent. > 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. This 90% is for CC-mode, where font-lock is particularly expensive. > 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. The 1st redisplay also only redrew the portion that was modified, which is pretty close in many cases to the portion that later gets fontified. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 29 10:16:44 2014 Received: (at 18856) by debbugs.gnu.org; 29 Oct 2014 14:16:44 +0000 Received: from localhost ([127.0.0.1]:38882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjU3H-0001Gb-P5 for submit@debbugs.gnu.org; Wed, 29 Oct 2014 10:16:44 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:54002) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjU3E-0001GH-90 for 18856@debbugs.gnu.org; Wed, 29 Oct 2014 10:16:41 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NE700I00LV72700@mtaout27.012.net.il> for 18856@debbugs.gnu.org; Wed, 29 Oct 2014 16:11:35 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NE700H0SM3B2U20@mtaout27.012.net.il>; Wed, 29 Oct 2014 16:11:35 +0200 (IST) Date: Wed, 29 Oct 2014 16:16:29 +0200 From: Eli Zaretskii Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83vbn30xmq.fsf@gnu.org> References: <87a94h2tpf.fsf@engster.org> <838uk02i9j.fsf@gnu.org> <831tps2dy7.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18856 Cc: 18856@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: deng@randomsample.de, 18856@debbugs.gnu.org > Date: Wed, 29 Oct 2014 00:06:14 -0400 > > >> 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? > > The user is waiting for Emacs to process the input that he's already sent. Using an idle timer does that, right? > > 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. > > This 90% is for CC-mode, where font-lock is particularly expensive. Yes, that's right. > > 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. > > The 1st redisplay also only redrew the portion that was modified, which > is pretty close in many cases to the portion that later gets fontified. I was thinking about scrolling with C-v, in which case the first redisplay redraws almost the entire window. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 29 11:01:34 2014 Received: (at 18856) by debbugs.gnu.org; 29 Oct 2014 15:01:34 +0000 Received: from localhost ([127.0.0.1]:38910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjUkf-0002Vw-I8 for submit@debbugs.gnu.org; Wed, 29 Oct 2014 11:01:33 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:43753) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjUkd-0002Vg-0O for 18856@debbugs.gnu.org; Wed, 29 Oct 2014 11:01:32 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NE700400O0CDN00@mtaout27.012.net.il> for 18856@debbugs.gnu.org; Wed, 29 Oct 2014 16:56:26 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NE7004LTO62FL00@mtaout27.012.net.il>; Wed, 29 Oct 2014 16:56:26 +0200 (IST) Date: Wed, 29 Oct 2014 17:01:20 +0200 From: Eli Zaretskii Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83k33i2a4f.fsf@gnu.org> References: <87a94h2tpf.fsf@engster.org> <83fve82lsn.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18856 Cc: 18856@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: David Engster , 18856@debbugs.gnu.org > Date: Tue, 28 Oct 2014 13:38:36 -0400 > > > I can overcome this problem if I add a call to > > internal-timer-start-idle at the end of compilation-handle-exit. > > Not sure this is TRT, though. > > I don't think this is right: as mentioned the issue is not specific to > compilation, so we'd really need to call internal-timer-start-idle from > the code that runs process-filters. > > And it implies a different definition of "idle" than the one we've had > so far, so it'd be an incompatible change. > > > then I see a single event, BUFFER_SWITCH_EVENT, being reported. > > Should input-pending-p ignore such events? > > I think so, yes, because these events are not (consciously) generated by > the user. Is the below an OK solution for the issues discussed here? If OK, I'd like to commit the compile.el part, the one that turns off jit-lock-deferral in compilation buffers, to the release branch, since it's a regression from Emacs 23. OK? --- src/keyboard.c~0 2014-10-19 07:08:12 +0300 +++ src/keyboard.c 2014-10-29 16:44:02 +0200 @@ -404,6 +404,7 @@ static struct timespec timer_last_idlene #define READABLE_EVENTS_DO_TIMERS_NOW (1 << 0) #define READABLE_EVENTS_FILTER_EVENTS (1 << 1) #define READABLE_EVENTS_IGNORE_SQUEEZABLES (1 << 2) +#define READABLE_EVENTS_IGNORE_BUFFER_SWITCH (1 << 3) /* Function for init_keyboard to call with no args (if nonzero). */ static void (*keyboard_init_hook) (void); @@ -3495,7 +3496,8 @@ readable_events (int flags) && event->part == scroll_bar_handle && event->modifiers == 0) #endif - ) + && !((flags & READABLE_EVENTS_IGNORE_BUFFER_SWITCH) + && event->kind == BUFFER_SWITCH_EVENT)) return 1; event++; if (event == kbd_buffer + KBD_BUFFER_SIZE) @@ -10019,10 +10021,12 @@ If CHECK-TIMERS is non-nil, timers that /* Process non-user-visible events (Bug#10195). */ process_special_events (); - return (get_input_pending ((NILP (check_timers) - ? 0 : READABLE_EVENTS_DO_TIMERS_NOW) - | READABLE_EVENTS_FILTER_EVENTS) - ? Qt : Qnil); + int flags = + READABLE_EVENTS_IGNORE_BUFFER_SWITCH | READABLE_EVENTS_FILTER_EVENTS; + + if (!NILP (check_timers)) + flags |= READABLE_EVENTS_DO_TIMERS_NOW; + return (get_input_pending (flags) ? Qt : Qnil); } DEFUN ("recent-keys", Frecent_keys, Srecent_keys, 0, 0, 0, --- lisp/progmodes/compile.el~ 2014-10-28 15:11:16 +0200 +++ lisp/progmodes/compile.el 2014-10-29 16:50:40 +0200 @@ -1975,6 +1975,12 @@ compilation-page-delimiter) ;; (set (make-local-variable 'compilation-buffer-modtime) nil) (compilation-setup) + ;; Turn off deferred fontifications in the compilation buffer, if + ;; the user turned them on globally. This is because idle timers + ;; aren't re-run after receiving input from a subprocess, so the + ;; buffer is left unfontified after the compilation exits, until + ;; some other input event happens. + (set (make-local-variable 'jit-lock-defer-time) nil) (setq buffer-read-only t) (run-mode-hooks 'compilation-mode-hook)) From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 29 18:16:10 2014 Received: (at 18856) by debbugs.gnu.org; 29 Oct 2014 22:16:11 +0000 Received: from localhost ([127.0.0.1]:39419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjbXG-0007WW-EL for submit@debbugs.gnu.org; Wed, 29 Oct 2014 18:16:10 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:48368) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XjbXD-0007Vt-2Y for 18856@debbugs.gnu.org; Wed, 29 Oct 2014 18:16:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0IAOatTlRFpY87/2dsb2JhbABcgw6DYtJRBAICgRwXAQF8hAMBAQMBViMQCzQSFBgNJIhLCctyAQEBAQYBAQEBHpEIB4RLBbIggW+CNIFgIYJ6AQEB X-IPAS-Result: Aq0IAOatTlRFpY87/2dsb2JhbABcgw6DYtJRBAICgRwXAQF8hAMBAQMBViMQCzQSFBgNJIhLCctyAQEBAQYBAQEBHpEIB4RLBbIggW+CNIFgIYJ6AQEB X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="95546339" Received: from 69-165-143-59.dsl.teksavvy.com (HELO pastel.home) ([69.165.143.59]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Oct 2014 18:16:00 -0400 Received: by pastel.home (Postfix, from userid 20848) id 6B86F7CFF; Wed, 29 Oct 2014 18:16:00 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used Message-ID: References: <87a94h2tpf.fsf@engster.org> <838uk02i9j.fsf@gnu.org> <831tps2dy7.fsf@gnu.org> <83vbn30xmq.fsf@gnu.org> Date: Wed, 29 Oct 2014 18:16:00 -0400 In-Reply-To: <83vbn30xmq.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 29 Oct 2014 16:16:29 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 18856 Cc: 18856@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> >> 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? >> The user is waiting for Emacs to process the input that he's already sent. > Using an idle timer does that, right? Huh? No, the user is waiting because Emacs hasn't replied yet. Idle timers are for when the user hasn't given any command, so Emacs is waiting, rather than the user. >> The 1st redisplay also only redrew the portion that was modified, which >> is pretty close in many cases to the portion that later gets fontified. > I was thinking about scrolling with C-v, in which case the first > redisplay redraws almost the entire window. Same difference: the 1st redisplay redraws almost the whole window, and the second as well because almost none of the text had been fontified earlier. You're right, that the amount of redraw is not always exactly the same, but I think that in many/most cases the two are comparable. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 29 18:23:58 2014 Received: (at 18856) by debbugs.gnu.org; 29 Oct 2014 22:23:58 +0000 Received: from localhost ([127.0.0.1]:39427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xjben-0007jY-FH for submit@debbugs.gnu.org; Wed, 29 Oct 2014 18:23:57 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:59012) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xjbel-0007jJ-Or for 18856@debbugs.gnu.org; Wed, 29 Oct 2014 18:23:56 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0IAOatTlRFpY87/2dsb2JhbABcgw6DYtJRBAICgRwXAQF8hAMBAQRWIxALNBIUGA0kiFTLcgEBAQEGAQEBAR6RCAeESwWyIIFvgjSBYCGCegEBAQ X-IPAS-Result: Aq0IAOatTlRFpY87/2dsb2JhbABcgw6DYtJRBAICgRwXAQF8hAMBAQRWIxALNBIUGA0kiFTLcgEBAQEGAQEBAR6RCAeESwWyIIFvgjSBYCGCegEBAQ X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="95546650" Received: from 69-165-143-59.dsl.teksavvy.com (HELO pastel.home) ([69.165.143.59]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Oct 2014 18:23:50 -0400 Received: by pastel.home (Postfix, from userid 20848) id 10D1C7CFF; Wed, 29 Oct 2014 18:23:50 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used Message-ID: References: <87a94h2tpf.fsf@engster.org> <83fve82lsn.fsf@gnu.org> <83k33i2a4f.fsf@gnu.org> Date: Wed, 29 Oct 2014 18:23:50 -0400 In-Reply-To: <83k33i2a4f.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 29 Oct 2014 17:01:20 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 18856 Cc: 18856@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > #define READABLE_EVENTS_FILTER_EVENTS (1 << 1) > #define READABLE_EVENTS_IGNORE_SQUEEZABLES (1 << 2) > +#define READABLE_EVENTS_IGNORE_BUFFER_SWITCH (1 << 3) I think we should not need a new such setting, and can simply use READABLE_EVENTS_FILTER_EVENTS (i.e. handle BUFFER_SWITCH_EVENT like we handle FOCUS_IN, and I'm surprised there aren't more in that set of "not really input" events). Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 29 23:40:09 2014 Received: (at 18856) by debbugs.gnu.org; 30 Oct 2014 03:40:09 +0000 Received: from localhost ([127.0.0.1]:39617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xjgam-0002Td-4I for submit@debbugs.gnu.org; Wed, 29 Oct 2014 23:40:08 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:52947) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xjgai-0002T1-7d for 18856@debbugs.gnu.org; Wed, 29 Oct 2014 23:40:06 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NE800L00MVZMZ00@mtaout24.012.net.il> for 18856@debbugs.gnu.org; Thu, 30 Oct 2014 05:33:00 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NE800DFEN70ZE70@mtaout24.012.net.il>; Thu, 30 Oct 2014 05:33:00 +0200 (IST) Date: Thu, 30 Oct 2014 05:39:54 +0200 From: Eli Zaretskii Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <837fzi1b05.fsf@gnu.org> References: <87a94h2tpf.fsf@engster.org> <838uk02i9j.fsf@gnu.org> <831tps2dy7.fsf@gnu.org> <83vbn30xmq.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18856 Cc: 18856@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: deng@randomsample.de, 18856@debbugs.gnu.org > Date: Wed, 29 Oct 2014 18:16:00 -0400 > > >> >> 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? > >> The user is waiting for Emacs to process the input that he's already sent. > > Using an idle timer does that, right? > > Huh? No, the user is waiting because Emacs hasn't replied yet. > Idle timers are for when the user hasn't given any command, so Emacs is > waiting, rather than the user. You said "_defer_ fontification when the user is waiting for Emacs". When user is waiting for Emacs, idle timers won't run, and therefore fontifications done in a function that runs off an idle timer will not be performed. How does this not fit what you describe? > >> The 1st redisplay also only redrew the portion that was modified, which > >> is pretty close in many cases to the portion that later gets fontified. > > I was thinking about scrolling with C-v, in which case the first > > redisplay redraws almost the entire window. > > Same difference: the 1st redisplay redraws almost the whole window, and > the second as well because almost none of the text had been > fontified earlier. The amount of redrawing depends on what portions of the visible text are fontified. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 30 00:10:28 2014 Received: (at 18856) by debbugs.gnu.org; 30 Oct 2014 04:10:29 +0000 Received: from localhost ([127.0.0.1]:39637 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xjh48-0003Ij-38 for submit@debbugs.gnu.org; Thu, 30 Oct 2014 00:10:28 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:27129) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xjh45-0003IT-Rz for 18856@debbugs.gnu.org; Thu, 30 Oct 2014 00:10:26 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0IAOatTlRFpY87/2dsb2JhbABcgw6DYtJRBAICgRwXAQF8hAMBAQMBViMFCws0EhQYDSSISwnLcgEBAQEGAQEBAR6RCAeESwWfEpB9ghGBb4I0gWAhgnoBAQE X-IPAS-Result: Aq0IAOatTlRFpY87/2dsb2JhbABcgw6DYtJRBAICgRwXAQF8hAMBAQMBViMFCws0EhQYDSSISwnLcgEBAQEGAQEBAR6RCAeESwWfEpB9ghGBb4I0gWAhgnoBAQE X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="95562254" Received: from 69-165-143-59.dsl.teksavvy.com (HELO pastel.home) ([69.165.143.59]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Oct 2014 00:10:20 -0400 Received: by pastel.home (Postfix, from userid 20848) id 0F0887CFF; Thu, 30 Oct 2014 00:10:20 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used Message-ID: References: <87a94h2tpf.fsf@engster.org> <838uk02i9j.fsf@gnu.org> <831tps2dy7.fsf@gnu.org> <83vbn30xmq.fsf@gnu.org> <837fzi1b05.fsf@gnu.org> Date: Thu, 30 Oct 2014 00:10:19 -0400 In-Reply-To: <837fzi1b05.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 30 Oct 2014 05:39:54 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 18856 Cc: 18856@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > You said "_defer_ fontification when the user is waiting for Emacs". > When user is waiting for Emacs, idle timers won't run, and therefore > fontifications done in a function that runs off an idle timer will not > be performed. How does this not fit what you describe? Your question was: Indeed, so what's the point of doing that? where AFAIK "that" referred to "defer fontification when input is pending". And I explained that the point of deferring fontification only when input is pending (as opposed to doing it all the time, as in the current jit-lock-defer-time system) is that we defer less often, more specifically we only defer "when we know for sure that the user is waiting for further processing". >> Same difference: the 1st redisplay redraws almost the whole window, and >> the second as well because almost none of the text had been >> fontified earlier. > The amount of redrawing depends on what portions of the visible text > are fontified. That's why I said "because almost none of the text had been fontified earlier". It's not always true, but the end result is the same: the double redisplay takes extra time. Does it take exactly twice the time? Maybe not exactly, but I think that a factor of 2 is a good enough approximation. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 01 10:24:52 2014 Received: (at 18856-done) by debbugs.gnu.org; 1 Nov 2014 14:24:52 +0000 Received: from localhost ([127.0.0.1]:44745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkZbo-0002f6-9a for submit@debbugs.gnu.org; Sat, 01 Nov 2014 10:24:52 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:63803) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XkZbl-0002ep-4z for 18856-done@debbugs.gnu.org; Sat, 01 Nov 2014 10:24:50 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NED00K0063BN000@a-mtaout22.012.net.il> for 18856-done@debbugs.gnu.org; Sat, 01 Nov 2014 16:24:42 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NED00K626P67Z70@a-mtaout22.012.net.il>; Sat, 01 Nov 2014 16:24:42 +0200 (IST) Date: Sat, 01 Nov 2014 16:24:27 +0200 From: Eli Zaretskii Subject: Re: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83ppd7xalg.fsf@gnu.org> References: <87a94h2tpf.fsf@engster.org> <83fve82lsn.fsf@gnu.org> <83k33i2a4f.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18856-done Cc: 18856-done@debbugs.gnu.org, deng@randomsample.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: deng@randomsample.de, 18856@debbugs.gnu.org > Date: Wed, 29 Oct 2014 18:23:50 -0400 > > > #define READABLE_EVENTS_FILTER_EVENTS (1 << 1) > > #define READABLE_EVENTS_IGNORE_SQUEEZABLES (1 << 2) > > +#define READABLE_EVENTS_IGNORE_BUFFER_SWITCH (1 << 3) > > I think we should not need a new such setting, and can simply use > READABLE_EVENTS_FILTER_EVENTS (i.e. handle BUFFER_SWITCH_EVENT like we > handle FOCUS_IN, and I'm surprised there aren't more in that set of "not > really input" events). I made the requested change in keyboard.c, and committed both parts, with the compile.el part on the emacs-24 branch. Closing. From unknown Fri Sep 05 11:01:08 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 30 Nov 2014 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator