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: Mon, 6 Dec 2021 20:53:15 +0000 [thread overview]
Message-ID: <Ya54O+2Dyjp6L/Ku@ACM> (raw)
In-Reply-To: <83sfv74hpm.fsf@gnu.org>
Hello, Eli.
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.
> 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 (!),
That is customisable with c-type-finder-repeat-time. The idea is to
have this as often as possible so that the backgroud scanning is
complete as soon as possible. (See my next paragraph.)
> and which for some reason forces Emacs to perform a redisplay cycle
> with that frequency. 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.
The idea is that this processing only happens a short while after
loading a C file, the time being taken up by checking for the
fontification of "found types", that is identifiers identified as types
in the rest of the buffer somewhere.
> Not even "emacs -Q -D" is enough to get rid of this
> 'c-type-finder-timer-func' timer in CC Mode buffers.
If this processing continues beyond the time to scan all CC Mode
buffers, then there is a bug. A megabyte long file (xdisp.c) scans in
aroung 18 seconds on my machine.
> 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.
It can be disabled by setting (or customising) c-type-finder-time-slot
to nil. As I say, the activity should cease after a few seconds, or a
few minutes with a well filled desktop.
There have been a couple of bugs in this area recently, one fixed
(stupidly) on the release branch (where there wasn't a problem). The
other one was fixed in master. By recently, I mean last Wednesday and
Saturday 2021-11-13.
But even given the above, I've a sneaking suspicion there's still a bug
here, which I'll have a look for (but not tonight).
> In GNU Emacs 29.0.50 (build 297, i686-pc-mingw32)
> of 2021-12-04 built on HOME-C4E4A596F7
> 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).
next prev parent reply other threads:[~2021-12-06 20:53 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 [this message]
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
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Ya54O+2Dyjp6L/Ku@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).