bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode

[Alan Mackenzie]

Hello, Eli.

Yes, I've received your more recent posts in this thread.

On Sun, Dec 05, 2021 at 09:46:29 +0200, Eli Zaretskii wrote:
> It used to be the case that starting "emacs -Q" and disabling
> blink-cursor-mode and global-eldoc-mode was enough to get me Emacs
> that doesn't perform redisplay unless required.  To see this, do the
> following with any Emacs up to and including Emacs 28:

>   emacs -Q
>   M-x blink-cursor-mode RET
>   M-x global-eldoc-mode RET
>   M-x trace-redisplay RET

> (The last command is only available if you configured with
> "--enable-checking=yes,glyphs".)  This would produce a few lines of
> output on stderr, and then stop until you do something in Emacs, like
> move the cursor with an arrow key.

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.  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



> This is no longer the case in Emacs 29.  There, if you visit a C file,
> you will see a flurry of stderr messages about constant redisplay
> cycles being forced.  It seems like the culprit is the function
> 'c-type-finder-timer-func', which is run from a timer at 10 Hz (!),
> and which for some reason forces Emacs to perform a redisplay cycle
> with that frequency. ....

I see the flurry of messages.  But with trace-redisplay disabled, I see
no evidence of excessive redisplay (see below).  Could it be that there
is some interaction between trace-redisplay and CC Mode which is causing
all these redisplayings?

> .... The trace itself, viz.:

>   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.
Thanks!

> Not even "emacs -Q -D" is enough to get rid of this
> 'c-type-finder-timer-func' timer in CC Mode buffers.

> 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.

What am I not seeing?

> In GNU Emacs 29.0.50 (build 297, i686-pc-mingw32)
>  of 2021-12-04 built on HOME-C4E4A596F7

I've checked the git log, and there haven't been any changes to CC Mode
since this version.

> Repository revision: f247fa5d5ce7cb34f23c979c17b14c5713eb5490
> Repository branch: master
> Windowing system distributor 'Microsoft Corp.', version 5.1.2600
> System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

> Configured using:
>  'configure -C --prefix=/d/usr --with-wide-int
>  --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).