[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: c-beginning-of-defun. Bugfixes in CC Mode (@SourceForge) not yet in
Re: c-beginning-of-defun. Bugfixes in CC Mode (@SourceForge) not yet in savannah
Fri, 15 Dec 2006 11:40:17 -0500
Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux)
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
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.