[Top][All Lists]

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

Re: cc-mode fontification feels random

From: Daniel Colascione
Subject: Re: cc-mode fontification feels random
Date: Wed, 09 Jun 2021 19:21:23 -0700
User-agent: AquaMail/1.29.2-1810 (build: 102900008)

On June 9, 2021 2:03:07 PM Alan Mackenzie <acm@muc.de> wrote:

Hello, Eli.

On Wed, Jun 09, 2021 at 21:36:44 +0300, Eli Zaretskii wrote:
Date: Wed, 9 Jun 2021 18:22:57 +0000
Cc: Daniel Colascione <dancol@dancol.org>, monnier@iro.umontreal.ca,
rudalics@gmx.at, emacs-devel@gnu.org, rms@gnu.org
From: Alan Mackenzie <acm@muc.de>

I think we agree.  Except that for me, it should also not try if it
cannot do it quickly enough, not only reliably enough.

Quickly and reliably enough are desirable things, but in competition
with eachother.  Reliably enough is a lot easier to measure, quickly
enough depends on the machine, the degree of optimisation, and above
all, the user's expectations.

That's why we had (and still have) font-lock-maximum-decoration: so
that users could control the tradeoff.  Unfortunately, support for
that variable is all but absent nowadays, because of the widespread
mistaken assumption that font-lock is fast enough in all modes.

That variable is still supported by CC Mode (with the exception of AWK
Mode, where it surely is not needed).

Another possibility would be to replace accurate auxiliary functionality
with rough and ready facilities.  In a scroll through xdisp.c, fontifying
as we go, the following three functions are taking around 30% of the

(i) c-bs-at-toplevel-p, which determines whether or not a brace is at the
 top level.
(ii) c-determine-limit, c-determine-+ve-limit, which determine search
 limits approximately ARG non-literal characters before or after point.

By replacing these accurate functions with rough ones, the fontification
would be right most of the time, but a mess at other times (for example,
when there are big comments near point).  (i) is more important for C++
that C, but still makes a difference i

Another option is adding core support to speed up these operations. I don't think we should be sacrificing correctness for speed.

If we were to try this, I think a user toggle would be needed.

IMHO, we should rely on LSP to figure out what symbols are types, and if
a LSP isn't available, we shouldn't try to guess.

"Shouldn't try to guess" means taking a great deal of
font-lock-type-faces out of CC Mode.  I don't honestly think the end
result would be any better than what we have at the moment.

You don't think it will be better for what reason?

Because many users will still want at least the basic types (int, double,
unsigned long, ....) fontified, leading to the very mess Daniel would
like to avoid.   Declarations with basic types tend to be interleaved
with those using project defined types.

I was talking about what to do (or not to do) with our existing
regexp- and "syntax"-based fontifications.  I still remember the days
when CC Mode handled that well enough without being a snail it
frequently is now, and that was on a machine about 10 times slower
than the one I use nowadays.

Those old versions had masses of fontification bugs in them.

I don't remember bumping into those bugs.  Or maybe they were not
important enough to affect my UX.  Slow redisplay, by contrast, hits
me _every_day_, especially if I need to work with an unoptimized
build.  From where I stand, the balance between performance and
accuracy have shifted to the worse, unfortunately.

OK.  My above suggestion might give ~50% increase in fontification speed.

People wrote bug reports about them and they got fixed.  Those fixes
frequently involved a loss of speed.  :-(

If there's no way of fixing a bug without adversely affecting speed,
we should add user options to control those "fixes", so that people
could choose the balance that fits them.

I think this would be a bad thing.  There are no (or very few) similar
user options in CC Mode at the moment, and an option to fix or not fix a
bug seems a strange idea, and would make the code quite a bit more

Sometimes Emacs could itself decide whether to invoke the "slow" code.
For example, it makes no sense for users of C to be "punished" because
we want more accurate fontification of C++ sources.

There is some truth in this imputation, yes.

There have also been several bug reports about unusual buffers
getting fontified at the speed of continental drift, and fixing those
has usually led to a little slowdown for ordinary buffers.  I'm
thinking, for example, about bug #25706, where a 4 MB file took
nearly an hour to scroll through on my machine.  After the fix, it
took around 86 seconds.

Once again, a pathological use case should not punish the usual ones;
if the punishment is too harsh, there should be a way to disable the
support for pathological cases for those who never hit them.

The punishment is rarely too harsh for a single bug.  But a lot of 2%s,
3%s or 5%s add up over time.  If we were to outlaw a "3% fix", then many
bugs would just be unsolvable.

The C language didn't change too much since then, at least not the
flavor I frequently edit.

There are two places where CC Mode can be slow: font locking large areas
of text, and keeping up with somebody typing quickly.  Which of these
bothers you the most?  I have plans for speeding up one of these.

Both, I guess.  Though the former is probably more prominent, since
I'm not really such a fast typist, but I do happen to scroll through
source quite a lot.

Thanks.  I'll try to come up with speedups in the coming weeks (and

Do you have fast-but-imprecise-scrolling enabled?  That can reduce the

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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