emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%
Date: Fri, 03 Sep 2021 14:24:31 +0300

> 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.  The only "arguments" you bring up are that you disagree
with my assessment.  I don't think those are useful arguments, because
who said your vision of the future is more accurate than mine?  But I
don't intend to continue arguing.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]