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

[Alan Mackenzie]

Hello, Eli.

On Fri, Sep 03, 2021 at 14:24:31 +0300, Eli Zaretskii wrote:
> > Date: Fri, 3 Sep 2021 10:47:41 +0000
> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Bother: this is not future-proof, and certainly isn't scalable.  If we
> > > are changing the protocol, can we instead come up with a more scalable
> > > change, so that functions won't "fight" in the future who gets to be
> > > "the first"?

> > I think we need to be clear about the current situation versus my
> > proposal.  If there is only one element (typically
> > font-lock-fontify-region) on jit-lock-functions, nothing changes.  With
> > several elements:

> > Current situation: The region marked with 'fontified text properties is
> > the _smallest_ returned by the jit-lock-functions functions.  If such a
> > function returns nil (which is usual), that region becomes precisely
> > (BEG END), and we lose all the benefit of jit-lock-bounds.

> > Proposed mechanism: The region marked with 'fontified is that supplied
> > by the first j-l-f function, typically font-lock-fontify-region.  This
> > is an enhancement.

> > Note that it is difficult to use the jit-lock-bounds returned by a
> > subsequent function, if they exceed the bounds returned by the first
> > function.  To do this safely, we would have to re-run all the previous
> > jit-lock-functions on the newly enlarged region.  This would be clumsy,
> > and wouldn't fit in well with our current scheme.

> > As for "fighting" to be the first function in j-l-f, I don't think that
> > should be a problem.  We can document the new &optional parameter to
> > jit-lock-register (not yet implemented) to say "don't use this unless
> > you really know what you're doing".

> > What we have isn't scalable in the sense you mean, and I don't think it
> > can be made scalable without massive changes in the jit-lock mechanism,
> > which might well reverse the benefits of using jit-lock-bounds (the 7%
> > saving in font locking time in CC Mode (and surely other modes, too)).

> You basically say that you consider what I said not important enough
> to handle.

That's not at all what I meant to say.  I'm sorry that it came out like
that.

> The only "arguments" you bring up are that you disagree with my
> assessment.

No.  The matter we're discussing is somewhat complicated, and I think
we're seeing different aspects of it.  That's why I wrote out in detail
what I am seeing.  I don't yet see what you're seeing.

> I don't think those are useful arguments, because who said your vision
> of the future is more accurate than mine?  ....

Not me.  But I think winning back that 7% of fontification speed is worth
the effort.  I think we're still at the stage of exploring alternatives.
Stefan has suggested one or two.

-- 
Alan Mackenzie (Nuremberg, Germany).