Re: c-beginning-of-defun. Bugfixes in CC Mode (@SourceForge) not yet in savannah

[Chong Yidong]

Alan Mackenzie <address@hidden> writes:

>> Should C mode do (setq beginning-of-defun-function
>> 'c-beginning-of-defun) Is there any reason that would be bad?
>
> Yes.  C-M-a should be bound directly to c-beginning-of-defun (as it is
> in the current address@hidden version).
>
> Unfortunately, in beginning-of-defun, b-o-d-function doesn't get passed
> the ARG, therefore needs to be called repeatedely in a loop from b-o-d.
> This makes optimisation for large ARG impossible.

Is this relevant to font-lock's use of beginning-of-defun?  If not, we
can ignore it for the time being.

> c-beginning-of-defun (the version in cc-mode.sourceforge) DOES optimise,
> bringing a factor of 10 speed-up for large ARG: I measured the following
> timings on my deceased 166 MHz box some while ago:  With a freshly
> opened src/keyboard.c, do M->.  Then time C-u 100 C-M-a:
>
>      Unoptimised version: 44 seconds.
>      Optimised version: 4 seconds.

Setting beginning-of-defun-function to c-beginning-of-defun and
hacking around the aforementioned limitations (with the CVS version of
CC mode), I observe that the first M-> still takes 4 seconds, though
subsequent calls are instantaneous.  Before, even the first M-> call
was instantaneous.

Also, I've experienced various strange lockups and performance
slowdowns with this approach.  I think this function is simply not
ready to be used for font-locking purposes.