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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Fri, Sep 03, 2021 at 09:10:24 +0300, Eli Zaretskii wrote:
> > Date: Thu, 2 Sep 2021 19:24:51 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: emacs-devel@gnu.org

> > In words (;-), only the first function on jit-lock-functions should
> > be able to expand the region which gets `fontified' text properties.
> > This expanded region will then be supplied to the subsequent
> > functions.

> > Given how little used the `jit-lock-bounds' mechanism is (there is
> > one function in Emacs, font-lock-default-fontify-region, which uses
> > it, and a web search revealed only a single other instance, in
> > lsp-mode on git-hub), this shouldn't cause problems.  In fact, I'm
> > not sure the lsp-mode use of it is even correct.

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

OK, so the problem is how do we cope with two (or even several) "first"
functions?

How about something like this:
o - We still have a first function, font-lock-fontify-region.
o - We call the next function with the jit-lock-bounds returned by the
  previous one.  Repeat this step with steadily expanding bounds for
  each function in jit-lock-functions.
o - if (< BEG-final BEG-1) we go through jit-lock-functions again on the
  region (BEG-final BEG-1).  Do the same for END-final.  During this
  stage, we ignore the returned jit-lock-bounds.
o - We set the `fontified' text properties on the region (BEG-final
  END-final).

This needn't actually be too complicated.  The current
jit-lock--run-functions already calculates BEG-final and END-final (it
calls them loose-beg and loose-end).

For this mechanism, it would still be best to have all the functions
using jit-lock-bounds together at the start of jit-lock-functions,
though this would be an optimsation rather than essential to the
functionality.

-- 
Alan Mackenzie (Nuremberg, Germany).