Re: [PATCH] Re: cc-mode fontification feels random

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Mon, Aug 30, 2021 at 22:25:31 +0300, Eli Zaretskii wrote:
> > Date: Mon, 30 Aug 2021 18:50:34 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: emacs-devel@gnu.org

> > The following patch is an attempt to improve this situation.  It is best
> > used with jit-stealth-lock enabled.  I have tried it out with the
> > following settings:

> >     jit-lock-stealth-load: 200 ; i.e. inactive.
> >     jit-lock-stealth-nice: 0.1 ; 100 ms between fontifying stealth
> >                                  chunks.
> >     jit-lock-stealth-time: 1   ; 1 second idle time before stealth kicks
> >                                  in.

> > Whenever a new found type is entered into the CC Mode table, it marks
> > all occurrences of the type in the buffer for fontification (by setting
> > the 'fontified text property to nil on it), and causes an immediate
> > redisplay when there are occurrences of the new type in a window.

> So you are saying that this will cause the display of the visible
> portion of the window to flicker whenever jit-lock-stealth finds such
> a "new type"?

There will be a one-time change from no fontification of foo to
font-lock-type-face.  The actual area of the screen getting refontified
is one declaration.

> That could annoy, can't it?

It might.  It didn't annoy me whilst trying it out.  The real question
is, will it annoy less than having types permanently unfontified.

> jit-lock-stealth is for fontifying portions of the buffer(s) that are
> not on display, it would be wrong for it to apply this enhancement, I
> think, certainly by default.

jit-lock has a presumption that the fontification of one part of a buffer
doesn't influence the fontification of another part.  This isn't the case
in CC Mode.

My impression is that jit-lock isn't much used.  It's disabled by
default.  What I'm envisaging is repurposing it to solve a real problem.

> And jit-lock-stealth-time of 1 sec is too short.  I use 16, because
> once jit-lock-stealth starts fontifying a chunk, Emacs can be
> relatively slow to react to keyboard input, so I prefer to let
> jit-lock-stealth start its thing only when there's a very good chance
> I indeed stopped typing, not just thinking about something for a
> second or two.

On my first try this evening with jit-lock, I set jit-lock-stealth-nice
to zero.  I completely lost control of my session, and hat to abort it
and restart.  But with the parameters set appropriately, can stealth
really make Emacs slow to react?

> > I think stealth lock could be enhanced by having it fontify several
> > 500-byte chunks together, say until 0.05s time has been taken up.  This
> > could speed up stealth fontification while still leaving the keyboard
> > responsive to the user.

> Users can already arrange for that by manipulating the
> jit-stealth-lock parameters.

I didn't see that this evening.  Stealth fontifies one chunk at a time,
then waits the "nice" time before fontifying the next chunk.  The time
for stealth to get through xdisp.c was several minutes, possibly even
many minutes.  This is unimportant for general background fontification,
but more important if using stealth to detect types.

> Why should we change code to force upon everyone what seems like a good
> idea to you (but isn't a good idea IME, see above)?

Well, I was thinking of these enhancements to stealth being more of an
option than forced upon people.  For example, a new variable
jit-lock-stealth-time-block could be nil by default, or set to 0.05 to
fontify for 0.05 seconds before attending to user input.

0.05 seconds is enough for about 5 500-byte chunks in CC Mode on my
machine.  That has the potential to speed up stealth fontification by a
factor a little less than 5.

> If you want that, you can easily arrange for Emacs to behave like that
> without changing any code.

I didn't see any way of doing it while looking at the code earlier on.
What exactly are you thinking of, here?

-- 
Alan Mackenzie (Nuremberg, Germany).