all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 52298@debbugs.gnu.org
Subject: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode
Date: Wed, 8 Dec 2021 20:15:46 +0000	[thread overview]
Message-ID: <YbEScn/xXG0G4nIQ@ACM> (raw)
In-Reply-To: <83sfv74hpm.fsf@gnu.org>

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





  parent reply	other threads:[~2021-12-08 20:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-05  7:46 bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Eli Zaretskii
2021-12-06 20:53 ` Alan Mackenzie
2021-12-07 12:58   ` Eli Zaretskii
2021-12-07 19:58     ` Alan Mackenzie
2021-12-07 20:16       ` Eli Zaretskii
2021-12-08 20:15 ` Alan Mackenzie [this message]
2021-12-09  7:08   ` Eli Zaretskii
2021-12-09 20:11     ` Alan Mackenzie
2021-12-09 20:38       ` Eli Zaretskii
2021-12-10 18:16         ` Alan Mackenzie
2021-12-10 18:51           ` Eli Zaretskii
2021-12-10 22:52             ` Alan Mackenzie
2021-12-11  7:59               ` Eli Zaretskii
2021-12-11 14:52                 ` Alan Mackenzie
2021-12-11 15:38                   ` Eli Zaretskii
2021-12-11 17:04                     ` Alan Mackenzie
2021-12-11 18:21                       ` Eli Zaretskii
2021-12-12  8:58                         ` Alan Mackenzie
2021-12-12  9:15                           ` Eli Zaretskii
2021-12-12 19:05                             ` Alan Mackenzie
2021-12-12 19:21                               ` Eli Zaretskii
2021-12-13 14:19                                 ` Alan Mackenzie
2021-12-12 23:31                               ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-13 14:25                                 ` Alan Mackenzie
2021-12-19 14:38                               ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YbEScn/xXG0G4nIQ@ACM \
    --to=acm@muc.de \
    --cc=52298@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.