Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Wed, Sep 01, 2021 at 21:01:55 +0300, Eli Zaretskii wrote:
> > Date: Wed, 1 Sep 2021 17:55:46 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > (I thought that the code in jit-lock.el already handled this case by
> > > computing a kind-of "maximum" out of all the return values of
> > > jit-lock-functions, and treating a nil return value as expected, but
> > > maybe my reading of the code was incorrect?)

> > I think it rather uses the "minimum", i.e. the region common to all the
> > return values from the jit-lock-functions.  If one of these values is nil
> > (as is the case here), that boils down to exactly the 500-byte chunk.

> Then I think the easiest fix is to get bug-reference-prog-mode return
> a suitable value, or wrap it in a function that would.  Every function
> that puts itself on jit-lock-functions without actually fontifying
> anything should return BOB..EOB as the region it fontified, right?

I'm not sure that's the right fix.  If font-lock mode were disabled, say,
bug-reference-fontify would be the only function on jit-lock-functions.
Then it would fontify the first chunk at BOB, return (jit-lock-bounds .
(BOB . EOB)), which would cause `fontified' to be set on the entire
buffer, and no further chunks would get fontified at all.

The mechanism with `jit-lock-bounds' in jit-lock.el is a good idea, but
somehow it's not quite optimal at the moment.  Maybe it could be
improved.  For example, if the first jit-lock-functions element returns
(... (new-BEG .  new-END)) we might be able to supply new-BEG, new-END as
the arguments to the second element.  Or something like that.

-- 
Alan Mackenzie (Nuremberg, Germany).