[Top][All Lists]

[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

From: Chong Yidong
Subject: Re: c-beginning-of-defun. Bugfixes in CC Mode (@SourceForge) not yet in savannah
Date: Fri, 15 Dec 2006 11:40:17 -0500
User-agent: 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
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]