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

[Alan Mackenzie]

Hello, Eli.

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

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

> But that never happens, does it?

I just did M-x font-lock-mode.  bug-reference-fontify was the only thing
left in jit-lock-functions.

> Or if we want to be holier than the Pope, bug-reference-fontify could
> check if it's the only function on the list, and then change its
> return value accordingly.

That's horrible!  ;-)  There might be two such functions that each
returns nil, and so on.

> > The mechanism with `jit-lock-bounds' in jit-lock.el is a good idea,
> > but somehow it's not quite optimal at the moment.

> It was designed for functions that actually fontify something.  We
> need to either extend it for functions that don't, or change those
> functions to pretend they do, but in a way that doesn't disrupt
> jit-lock-bounds.

I'm more in favour of enhancing the mechanism in jit-lock.el.  The
protocol to the fontifying functions is very stable, robust, and simple.

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

> I think it's too late to change the protocol, since it was in use for
> too long.

Does that change the protocol?  It merely gives a different chunk to the
later functions.  Given that they're expecting a sequence of contiguous
chunks in successive invocations, why does it matter if we pass (501
1050), (1050 2000), .... as successive argument regions rather than (501
1001), (1001 1501)?

There seem to be two types of jit-lock-functions elements.  The first,
which uses the `jit-lock-bounds' mechanism and the second which returns
a random value like nil.  I'm only aware of font-lock-fontify-region in
the first type.

So all we need to do is make sure that f-l-fontify-region is the first
function in jit-lock-functions.  All we need for that is an &optional
parameter to jit-lock-register meaning "put this function first in the
list".  Maybe.

Perhaps Stefan will say something about this problem.

-- 
Alan Mackenzie (Nuremberg, Germany).