[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Advising in cc-awk.el and namespace
From: |
Stefan Monnier |
Subject: |
Re: Advising in cc-awk.el and namespace |
Date: |
Fri, 11 Jul 2003 13:35:36 -0400 |
> load a large file (say, ..../emacs/src/keyboard.c) wait for jit-lock to
> finish fontifying it in the background, then make a small change near the
> beginning of this file, needlessly refontifying ~320kBytes consumes ~55%
> of the CPU's power for 3½ minutes.
>
> Why does a small change near the beginning refontify the whole file?
> I suppose there are some small changes that might legitimately do so,
> but I would not expect most small changes to do so. What's up?
Because in general, it might be necessary and font-lock does
not try to be clever here.
Basically syntactic-fontification (fontification of comments and string)
depends on the output of `syntax-ppss' and because font-lock-keyword
rules are order-dependent (they typically are only applied if there isn't
already some fontification at point, so that keywords aren't highlighted
inside strings), after redoing syntactic-fontification, keywords
fontification needs to be redone as well.
A change at pos N potentially changes the output of syntax-ppss for
all pos>N, so jit-lock just refontifies everything (in the background
with jit-lock-stealth-*). Of course, in practice the output of
syntax-ppss is generally not changed for all pos>N but only for N<pos<M
(or sometimes it is changed for all pos>N but the change is marginal or
irrelevant and will not influence the result of font-locking), so we could
be more clever, but we would need to cache the parse-state-before-change
so we can compare it to the parse-state-after-change so we can stop when
they are equal again. It might be worth the effort, but nobody has
bothered coding it up yet. Turning off jit-lock-stealth-* is a simpler
workaround for the CPU-power-wasting problem.
Stefan