Re: fontlock-speed
On 08 Feb 2002, Stephen J. Turnbull spake:
Remember all we're doing here is to _indent one line_. In the
case of
the TAB (which causes twice as many scans!!), font-lock should not
change anything---if it does there's a bug! Arguably font-lock (less
likely, cc-mode) is broken. In languages where indentation is not
syntactically significant, there is no good reason for changes in
indentation to cause XEmacs to go charging up and down the buffer
scanning sexps.
Um, since C is a (somewhat) context-sensitive language, and since
cc-mode doesn't actually know the grammar of C properly, arbitrary
amounts of chasing over the buffer may be required to work out what the
right indentation should be (it has to go to the top of the defun then
count bracelike constructs all the way down to point, at least). In some
(admittedly pathological) cases involving K&R declarations and/or
hanging-brace K&R brace style, it may have to chase all the way up to
the top of the buffer and back down to work out what your indentation
level is.
And there are scan-sexps calls in `c-forward-token-1',
`c-backward-token-1', and `c-parse-state', which are the workhorses of
the cc-mode indentation engine; the first two of these are called
basically all the time :)
I don't think this will be fixable without truly massive changes to
cc-mode (which would probably cripple its indentation engine again).
--
`It is to be proven that Linux Kernel is the most stable than MS Windows
that it uses less stable.' --- Bryan Parkoff being very comprehensible