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

[Alan Mackenzie]

Hello, Eli.

On Thu, Dec 09, 2021 at 09:08:16 +0200, Eli Zaretskii wrote:
> > Date: Wed, 8 Dec 2021 20:15:46 +0000
> > Cc: bug-gnu-emacs@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

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

Of course.  Still, when trace-redisplay is running on my system, the
amount of CPU usage is still around 1% of a core for this Emacs.

[ .... ]

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

The timer function is setting `fontified' text properties to nil.  It is
doing this inside a with-silent-modifications.  (Sorry I didn't answer
this question yesterday evening; I should have done.)

Have I misunderstood this action?  I thought that merely setting the
`fontified' text property to nil on a part of the buffer doesn't
instantaneously trigger redisplay (except by the calling of
after-change-functions, which is here inactive due to
`with-silent-modifications'), even if that part of the buffer is
currently displayed in a window.

If I _have_ misunderstood this, it is very likely the reason for the
flurry of redisplayings.  I think I need to read bits of xdisp.c rather
carefully.

[ .... ]

> > When I apply the following patch to cc-fonts.el:

[ .... ]

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

OK.  I need to understand xdisp.c a little better.

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

Again, the code is indeed using with-silent-modifications, and again,
sorry for not saying so yesterday evening.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).