From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Date: Thu, 09 Dec 2021 09:08:16 +0200 Message-ID: <83wnkeuufz.fsf@gnu.org> References: <83sfv74hpm.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17385"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 52298@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 09 08:09:21 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mvDYP-0004NQ-6E for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 09 Dec 2021 08:09:21 +0100 Original-Received: from localhost ([::1]:45164 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mvDYN-0007rn-7E for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 09 Dec 2021 02:09:19 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39132) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvDY6-0007re-2n for bug-gnu-emacs@gnu.org; Thu, 09 Dec 2021 02:09:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58948) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mvDY5-0006PF-Qi for bug-gnu-emacs@gnu.org; Thu, 09 Dec 2021 02:09:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mvDY5-0005N1-LP for bug-gnu-emacs@gnu.org; Thu, 09 Dec 2021 02:09:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Dec 2021 07:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52298 X-GNU-PR-Package: emacs Original-Received: via spool by 52298-submit@debbugs.gnu.org id=B52298.163903372020611 (code B ref 52298); Thu, 09 Dec 2021 07:09:01 +0000 Original-Received: (at 52298) by debbugs.gnu.org; 9 Dec 2021 07:08:40 +0000 Original-Received: from localhost ([127.0.0.1]:42261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvDXj-0005MM-Ua for submit@debbugs.gnu.org; Thu, 09 Dec 2021 02:08:40 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvDXi-0005MA-P6 for 52298@debbugs.gnu.org; Thu, 09 Dec 2021 02:08:39 -0500 Original-Received: from [2001:470:142:3::e] (port=60822 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvDXd-0006MG-De; Thu, 09 Dec 2021 02:08:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=XG3Vfd7lqPdqZb/g/88JK/Dm0GthzKFDTaoKq1Wvv5s=; b=oV7RVqvucddI zrS3N32d4oSKMTYXmV9EfB/tRw1ntRmjj8kQDyqllsK/v5OgRVwMb9AV5HAK6Cbw33sNT3fuxm13D 6epBhzQT1pTxQVDG7FczBF24+lGkQ0KmJOrPiKEibflQuJCHfhN4Oz0Ep7fmtUjP+4kq8PiQRPE3o IvX4suZ0KCqY18Q7w2DTxo5+dnjiorao8tDbPn9WVzrh//s8bXFFiTVr/sXmDqYSe4ZO8cMm5N7IP fexQn1BwJniF0q4jsiRuJpg7GhxjSw7OuBri8/4Wn/VpmFDRhqNi7NBV5xmBny3ajukzYpFs+FFdc WBFLwqziIREYCbLyrSJM6A==; Original-Received: from [87.69.77.57] (port=4178 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvDXd-0001tE-1i; Thu, 09 Dec 2021 02:08:33 -0500 In-Reply-To: (message from Alan Mackenzie on Wed, 8 Dec 2021 20:15:46 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:221978 Archived-At: > Date: Wed, 8 Dec 2021 20:15:46 +0000 > Cc: bug-gnu-emacs@gnu.org > From: Alan Mackenzie > > I've just tried building with that ./configure option, and trying out > M-x trace-redisplay with emacs -Q on a very recent master version. > > The command is not very useful on a Linux console. I didn't suggest that you invoke that command, it is not part of this issue. It is just a tool I used to see what's going on, and I do know how to interpret its output. And yes, if your main development environment is based on the Linux console, then many tools will be unavailable to you, but that's a tangent. > It outputs messages > on the same display thing that Emacs itself is using, and outputs them > as if they were a Unix text file being naively displayed in Windows: > i.e. like this: > > aaaa > aaaaaaaaaaaaa > aaaaaaaaaaaaa > aaaaaaaaaaaaaaa > aaaaaaaaaaaaaaaaaa That's not related to Windows, that's because Emacs switches the terminal to a mode where newline doesn't cause the cursor to move to the beginning of the next line. IOW, this is because you are running Emacs on the Linux console and the traces go to the same console, which is not configured to receive simple printf's. > > redisplay_internal 0 > > 071a03c8 (xdisp.c): try_window_id 2 > > redisplay_preserve_echo_area (8) > > > means that the processing induced by that timer function is far from > > being trivial, which means something that this function does causes > > Emacs to think some real change might have happened in the buffer. > > I'm not familiar with such traces, and trace-redisplay is not documented > in its doc string. Could you please explain briefly what the "071a03c8 > (xdisp.c):" means, and what says that the processing is non-trivial. The address and the file name are for when you run under GDB. The important part of that message is "try_window_id 2". If you look in xdisp.c for the trace that emits it, viz.: debug_method_add (w, "try_window_id %d", tem); you will realize that redisplay called try_window_id, which means it was working too hard: since nothing has changed in the buffer, and even point didn't move, it should have succeeded in the call to try_cursor_movement, which is before it. So something prevented try_cursor_movement from succeeding in this case, and kept preventing that for full 4 minutes after the file was visited. The question is: what is that something that causes try_cursor_movement to fail? > > Is it possible to prevent this frequent timer from firing when no > > changes have been done to the buffer? And in any case, please try to > > include some logic in that function to avoid whatever it does now to > > force such frequent non-trivial redisplay cycles. If nothing else, > > laptop users will hate us if we release Emacs with this behavior. > > When I apply the following patch to cc-fonts.el: > > diff --git a/lisp/progmodes/cc-fonts.el b/lisp/progmodes/cc-fonts.el > index 967464ac14..2ae92f99bf 100644 > --- a/lisp/progmodes/cc-fonts.el > +++ b/lisp/progmodes/cc-fonts.el > @@ -2429,6 +2429,11 @@ c-re-redisplay-timer > (defun c-force-redisplay (start end) > ;; Force redisplay immediately. This assumes `font-lock-support-mode' is > ;; 'jit-lock-mode. Set the variable `c-re-redisplay-timer' to nil. > +;;;; TEMPORARY STOUGH, 2021-12-08 > + (message "c-force-redisplay - Buffer: %s - %s:%s - \"%s\"" > + (buffer-name (current-buffer)) start end > + (buffer-substring-no-properties start end)) > +;;;; END OF TEMPORARY STOUGH. > (save-excursion (c-font-lock-fontify-region start end)) > (jit-lock-force-redisplay (copy-marker start) (copy-marker end)) > (setq c-re-redisplay-timer nil)) > > , and load xdisp.c freshly, I see only three lines of output in > *Messages*: > > c-force-redisplay - Buffer: xdisp.c - 223:225 - "it" > c-force-redisplay - Buffer: xdisp.c - 49:55 - "buffer" > c-force-redisplay - Buffer: xdisp.c - 28:34 - "window" > > That applies after waiting over a minute. After this time, the `top' > utility shows Emacs consuming around 1% of a CPU core's time. > > All this suggests that in normal use, CC Mode isn't triggering excessive > redisplay operations. No, it means that your hypothesis regarding what causes the phenomenon was incorrect. Something else prevents try_cursor_movement from successfully deciding that the window doesn't need any redisplay. That something is in the timer function the CC Mode runs. If you can find what that factor is and remove it, it will solve the issue. In a followup message I wrote: > Is your code using with-silent-modifications, or some other mechanism > that should prevent Emacs from thinking that the buffer has changed? > If not, why not? Can you please answer that? It might be the key to unlock this issue, since you said that timer function puts text properties on buffer text. Thanks.