Re: Mysterious fontification/C++ context issue - Patch for beginning-of-defun-raw.

[Alan Mackenzie]

Good morning/evening, Chong!

On Wed, Dec 13, 2006 at 08:02:37PM -0500, Chong Yidong wrote:
> >> In any case, could someone check in Martin's optimization to
> >> c-beginning-of-defun-raw, or send me the patch with a changelog so
> >> that I can check it in?

> > Chong, especially: Please load xdisp.c with the following patch, and tell
> > me whether or not its slowness is still a problem.

> Before the changes beginning-to-defun-raw, doing M-> to move to the
> end of xdisp.c is instantaneous.

Hey, that's not fair!  When you raised this problem, you were
complaining about how slow a M-v was, after having got to EOF.  Is this
M-v now acceptably fast for you on your 1.7 GHz machine?

> With the patch applied, M-> takes four seconds.  This is on a Pentium 4
> 1700MHz computer.

It's worth pointing out that this is only the first time.  If you then
do M-< and another M->, these are then instantaneous.  If (some) cache
later gets disrupted, then the M-> would be a bit slow again.

Do you have any idea why M->, which is surely nothing more than
(goto-char (point-max)) is so slow?  I have an idea it is the filling of
CC Mode's cache.

> Is it really so bad to revert the changes for now?

Yes.

By "for now", you mean for Emacs 22.  If the changes are reverted "for
now", they'll stay reverted until the release of Emacs 23, sometime
around 2011.

> If the only files misfontified are Emacs source files, I don't think
> this "fix" is necessary for Emacs 22---especially if the files in
> question can be tweaked to avoid the bug.

It isn't only Emacs source files.  It happens a lot in normal users'
files.c.  There's a FAQ about it in the CC Mode manual.  After all,
having parentheses inside strings and comments in C is perfectly valid
and acceptable syntax, and it looks like a bug (which indeed it is), if
Emacs can't fontify such things properly.

xdisp.c, at ~750k, is an unusually large source file.  A 1.7 GHz machine
will become unusually old and slow during the lifetime of Emacs 22.

> (AFAIK, the issue of how to see this problem was never discussed on
> this mailing list, but I've certainly never come across it in my
> frequent perusal of the Emacs sources.)

The problem here is that CC Mode sets opic0ids to nil in a hard coded
fashion.  The solution must be that opic0ids in CC Mode should be nil by
default, yet give the user a way to set it to t.  How about the
following:

open-paren-in-column-0-is-defun-start should become a buffer-local
variable, with default value 'mode.  This symbol will mean "use the
major mode's default for the variable".  This will give the user the
flexibility she needs.

-- 
Alan.