Re: cc-mode fontification feels random

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sat, Jun 12, 2021 at 11:08:30 +0300, Eli Zaretskii wrote:
> > From: Daniel Colascione <dancol@dancol.org>
> > CC: <monnier@iro.umontreal.ca>, <rudalics@gmx.at>, <rms@gnu.org>, <emacs-devel@gnu.org>
> > Date: Sat, 12 Jun 2021 01:00:22 -0700

> > > It is a problem given how much the current fast machines can do during
> > > that time.  At 3 GHz, 30 msec of CPU time is equivalent to 100 million
> > > machine instructions.

> > And if you count electrons, the numbers are in the trillions. So what? Who 
> > cares how many machine instructions it is? What matters is the latency.

> I'm saying that, given how much these machines can do in 30 msec, it
> doesn't sound right that we cannot refontify 35 lines of text with all
> that processing power.  It tells me that our code is either very
> inefficient or does a lot of unnecessary processing (or both).

Or, due to the quirks of the CC Mode languages, it simply needs that
much processing to do an accurate job (or all three).

> Alan thought that the performance we have is acceptable.  The numbers
> I mentioned would hopefully convince him otherwise.

I think the performance is fully acceptable to a normal user on a 3.4
GHz modern machine.  If the processing power is available, why not make
use of it?

> > > We should either find a way of making this analysis faster, or give up
> > > on fontifying these two cases differently.  It is IMO unacceptable
> > > that redisplay is slowed down so much by mode-specific fontifications.

As mentioned already, we have the facility of setting
font-lock-maximum-decoration to 2, which triples fontification speed.
This comes at the cost of accuracy.  A lot of the bug reports I've
fielded over the years have been about fontification inaccuracies.

> > This is a great example of where incorrect fontification diminishes the 
> > utility of syntax highlighting more generally. If I can't trust the color 
> > of a symbol to distinguish a variable declaration from a type declaration, 
> > why bother fontifying as either?

> I think we are saying the same, just in different words.

> Do you agree that slowing down redisplay so much due to fontification
> is unacceptable?

I think I would answer that on a modern machine (certainly from the last
5 years), using a normally optimised Emacs build, the fontification
isn't slowed down.  On a somewhat slower machine, it could become
unacceptable, but that there are accpetable workarounds (setting
font-lock-maximum-decoration, or enabling fast-but-imprecise-scrolling,
or enabling deferred fontification).  On a much slower machine, the
above doesn't hold, no.

I can't agree that we should expect C Mode to fontify with around the
same amount of processing as Emacs Lisp Mode.  This isn't reasonable.

-- 
Alan Mackenzie (Nuremberg, Germany).