GNU bug report logs - #10652
24.0.93; font-lock very slow for C++

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10652 in the body.
You can then email your comments to 10652 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.93; font-lock very slow for C++
Date: Mon, 30 Jan 2012 12:15:52 +0100

Font lock is extremely slow in this file:

http://hg.openjdk.java.net/jdk7/jdk7/hotspot/raw-file/b92c45f2bc75/src/share/vm/runtime/globals.hpp

Download the file and open it with emacs -Q globals.hpp.  Then
scroll around in the file to see how slow it is.

Message #8 received at 10652 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Alan Mackenzie  <acm <at> muc.de>
Cc: Helmut Eller <eller.helmut <at> gmail.com>, 10652 <at> debbugs.gnu.org
Subject: Re: bug#10652: 24.0.93; font-lock very slow for C++
Date: Sun, 26 Feb 2012 17:47:25 +0800

Helmut Eller <eller.helmut <at> gmail.com> writes:

> Font lock is extremely slow in this file:
>
> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/raw-file/b92c45f2bc75/src/share/vm/runtime/globals.hpp
>
> Download the file and open it with emacs -Q globals.hpp.  Then
> scroll around in the file to see how slow it is.

I got Emacs into an uninterruptible loop while scrolling through the
buffer :-(

Looks like a regression against Emacs 23's CC mode, which handles the
file just fine.  Alan, could you investigate?  Thanks.

Message #11 received at 10652 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Chong Yidong <cyd <at> gnu.org>
Cc: Helmut Eller <eller.helmut <at> gmail.com>, 10652 <at> debbugs.gnu.org
Subject: Re: bug#10652: 24.0.93; font-lock very slow for C++
Date: Thu, 1 Mar 2012 19:36:22 +0000

Hello Yidong, hello Helmut.

On Sun, Feb 26, 2012 at 05:47:25PM +0800, Chong Yidong wrote:
> Helmut Eller <eller.helmut <at> gmail.com> writes:

> > Font lock is extremely slow in this file:

> > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/raw-file/b92c45f2bc75/src/share/vm/runtime/globals.hpp

> > Download the file and open it with emacs -Q globals.hpp.  Then
> > scroll around in the file to see how slow it is.

> I got Emacs into an uninterruptible loop while scrolling through the
> buffer :-(

> Looks like a regression against Emacs 23's CC mode, which handles the
> file just fine.  Alan, could you investigate?  Thanks.

OK.  First point: this is the first time I've ever seen a file with a
3350 line macro.  ;-)  There are several places in CC Mode which assume
macros are small, so it's not too surprising that this file goes slowly.

I've elp'd the scrolling, and have the following fix as a first
approximation.  Please try it out, but it's not fully tested, so don't
use it in anger.

Just one thing: if you've already got CC Mode running when you load in
this version, please do

    (setq-default c-macro-names-with-semicolon nil)

before M-x c++-mode, to clear out a stale value.

There are more optimisations I'm looking at at the moment.  Here's the
patch:


diff -r 915250820ea6 cc-engine.el
--- a/cc-engine.el	Wed Feb 29 18:59:34 2012 +0000
+++ b/cc-engine.el	Thu Mar 01 19:23:24 2012 +0000
@@ -222,6 +222,38 @@
 	       (point))))
     c-macro-start))
 
+;; One element macro cache to cope with continual movement within very large
+;; CPP macros.
+(defvar c-macro-cache nil)
+(make-variable-buffer-local 'c-macro-cache)
+;; Nil or cons of the bounds of the most recent CPP form probed by
+;; `c-beginning-of-macro', `c-end-of-macro' or `c-syntactic-end-of-macro'.
+;; The cdr will be nil if we know only the start of the CPP form.
+(defvar c-macro-cache-start-pos nil)
+(make-variable-buffer-local 'c-macro-cache-start-pos)
+;; The starting position from where we determined `c-macro-cache'.
+(defvar c-macro-cache-syntactic nil)
+(make-variable-buffer-local 'c-macro-cache-syntactic)
+;; non-nil iff `c-macro-cache' has both elements set AND the cdr is at a
+;; syntactic end of macro, not merely an apparent one.
+
+(defun c-invalidate-macro-cache (beg end)
+  ;; Called from a before-change function.  If the change region is before or
+  ;; in the macro characterised by `c-macro-cache' etc., nullify it
+  ;; appropriately.  BEG and END are the standard before-change-functions
+  ;; parameters.  END isn't used.
+  (cond
+   ((null c-macro-cache))
+   ((< beg (car c-macro-cache))
+    (setq c-macro-cache nil
+	  c-macro-cache-start-pos nil
+	  c-macro-cache-syntactic nil))
+   ((and (cdr c-macro-cache)
+	 (< beg (cdr c-macro-cache)))
+    (setcdr c-macro-cache nil)
+    (setq c-macro-cache-start-pos beg
+	  c-macro-cache-syntactic nil))))
+
 (defun c-beginning-of-macro (&optional lim)
   "Go to the beginning of a preprocessor directive.
 Leave point at the beginning of the directive and return t if in one,
@@ -229,19 +261,36 @@
 
 Note that this function might do hidden buffer changes.	 See the
 comment at the start of cc-engine.el for more info."
-  (when c-opt-cpp-prefix
-    (let ((here (point)))
-      (save-restriction
-	(if lim (narrow-to-region lim (point-max)))
-	(beginning-of-line)
-	(while (eq (char-before (1- (point))) ?\\)
-	  (forward-line -1))
-	(back-to-indentation)
-	(if (and (<= (point) here)
-		 (looking-at c-opt-cpp-start))
-	    t
-	  (goto-char here)
-	  nil)))))
+  (let ((here (point)))
+    (when c-opt-cpp-prefix
+      (if (and (car c-macro-cache)
+	       (>= (point) (car c-macro-cache))
+	       (or (and (cdr c-macro-cache)
+			(<= (point) (cdr c-macro-cache)))
+		   (<= (point) c-macro-cache-start-pos)))
+	  (unless (< (car c-macro-cache) (or lim (point-min)))
+	    (progn (goto-char (max (or lim (point-min)) (car c-macro-cache)))
+		   (setq c-macro-cache-start-pos
+			 (max c-macro-cache-start-pos here))
+		   t))
+	(setq c-macro-cache nil
+	      c-macro-cache-start-pos nil
+	      c-macro-cache-syntactic nil)
+
+	(save-restriction
+	  (if lim (narrow-to-region lim (point-max)))
+	  (beginning-of-line)
+	  (while (eq (char-before (1- (point))) ?\\)
+	    (forward-line -1))
+	  (back-to-indentation)
+	  (if (and (<= (point) here)
+		   (looking-at c-opt-cpp-start))
+	      (progn
+		(setq c-macro-cache (cons (point) nil)
+		      c-macro-cache-start-pos here)
+		t)
+	    (goto-char here)
+	    nil))))))
 
 (defun c-end-of-macro ()
   "Go to the end of a preprocessor directive.
@@ -251,12 +300,24 @@
 
 Note that this function might do hidden buffer changes.	 See the
 comment at the start of cc-engine.el for more info."
-  (while (progn
-	   (end-of-line)
-	   (when (and (eq (char-before) ?\\)
-		      (not (eobp)))
-	     (forward-char)
-	     t))))
+   (if (and (cdr c-macro-cache)
+	    (<= (point) (cdr c-macro-cache))
+	    (>= (point) (car c-macro-cache)))
+       (goto-char (cdr c-macro-cache))
+     (unless (and (car c-macro-cache)
+		  (<= (point) c-macro-cache-start-pos)
+		  (>= (point) (car c-macro-cache)))
+       (setq c-macro-cache nil
+	     c-macro-cache-start-pos nil
+	     c-macro-cache-syntactic nil))
+     (while (progn
+	      (end-of-line)
+	      (when (and (eq (char-before) ?\\)
+			 (not (eobp)))
+		(forward-char)
+		t)))
+     (when (car c-macro-cache)
+       (setcdr c-macro-cache (point)))))
 
 (defun c-syntactic-end-of-macro ()
   ;; Go to the end of a CPP directive, or a "safe" pos just before.
@@ -271,12 +332,15 @@
   ;; at the start of cc-engine.el for more info.
   (let* ((here (point))
 	 (there (progn (c-end-of-macro) (point)))
-	 (s (parse-partial-sexp here there)))
-    (while (and (or (nth 3 s)	 ; in a string
-		    (nth 4 s))	 ; in a comment (maybe at end of line comment)
-		(> there here))	 ; No infinite loops, please.
-      (setq there (1- (nth 8 s)))
-      (setq s (parse-partial-sexp here there)))
+	 s)
+    (unless c-macro-cache-syntactic
+      (setq s (parse-partial-sexp here there))
+      (while (and (or (nth 3 s)	 ; in a string
+		      (nth 4 s)) ; in a comment (maybe at end of line comment)
+		  (> there here))	; No infinite loops, please.
+	(setq there (1- (nth 8 s)))
+	(setq s (parse-partial-sexp here there)))
+      (setq c-macro-cache-syntactic (car c-macro-cache)))
     (point)))
 
 (defun c-forward-over-cpp-define-id ()
diff -r 915250820ea6 cc-fonts.el
--- a/cc-fonts.el	Wed Feb 29 18:59:34 2012 +0000
+++ b/cc-fonts.el	Thu Mar 01 19:23:24 2012 +0000
@@ -409,7 +409,8 @@
 	       (cc-eval-when-compile
 		 (boundp 'parse-sexp-lookup-properties)))
 	      (BOD-limit
-	       (c-determine-limit 1000)))
+	       (c-determine-limit 500 ;; 1000
+				  )))
 	  (goto-char
 	   (let ((here (point)))
 	     (if (eq (car (c-beginning-of-decl-1 BOD-limit)) 'same)
diff -r 915250820ea6 cc-langs.el
--- a/cc-langs.el	Wed Feb 29 18:59:34 2012 +0000
+++ b/cc-langs.el	Thu Mar 01 19:23:24 2012 +0000
@@ -444,8 +444,10 @@
   ;; For documentation see the following c-lang-defvar of the same name.
   ;; The value here may be a list of functions or a single function.
   t nil
-  c++ '(c-extend-region-for-CPP c-before-change-check-<>-operators)
-  (c objc) 'c-extend-region-for-CPP
+  c++ '(c-extend-region-for-CPP
+	c-before-change-check-<>-operators
+	c-invalidate-macro-cache)
+  (c objc) '(c-extend-region-for-CPP c-invalidate-macro-cache)
   ;; java 'c-before-change-check-<>-operators
   awk 'c-awk-record-region-clear-NL)
 (c-lang-defvar c-get-state-before-change-functions
diff -r 915250820ea6 cc-vars.el
--- a/cc-vars.el	Wed Feb 29 18:59:34 2012 +0000
+++ b/cc-vars.el	Thu Mar 01 19:23:24 2012 +0000
@@ -1653,7 +1653,8 @@
 		    c-macro-names-with-semicolon))))))
     
 (defvar c-macro-names-with-semicolon
-  '("Q_OBJECT" "Q_PROPERTY" "Q_DECLARE" "Q_ENUMS")
+;  '("Q_OBJECT" "Q_PROPERTY" "Q_DECLARE" "Q_ENUMS")
+  nil
   "List of #defined symbols whose expansion ends with a semicolon.
 Alternatively it can be a string, a regular expression which
 matches all such symbols.



-- 
Alan Mackenzie (Nuremberg, Germany).

Message #14 received at 10652 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Chong Yidong <cyd <at> gnu.org>
Cc: Helmut Eller <eller.helmut <at> gmail.com>, 10652 <at> debbugs.gnu.org
Subject: Re: bug#10652: 24.0.93; font-lock very slow for C++
Date: Fri, 2 Mar 2012 22:27:47 +0000

Hello Yidong, hello Helmut.

On Sun, Feb 26, 2012 at 05:47:25PM +0800, Chong Yidong wrote:
> Helmut Eller <eller.helmut <at> gmail.com> writes:

> > Font lock is extremely slow in this file:

> > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/raw-file/b92c45f2bc75/src/share/vm/runtime/globals.hpp

> > Download the file and open it with emacs -Q globals.hpp.  Then
> > scroll around in the file to see how slow it is.

> I got Emacs into an uninterruptible loop while scrolling through the
> buffer :-(

> Looks like a regression against Emacs 23's CC mode, which handles the
> file just fine.  Alan, could you investigate?  Thanks.

I've just committed a collection of optimisations as revision #107485.  I
can now scroll through the huge macro in that file quite quickly.

However, typing in the buffer is still suboptimal.  I don't know how much
I'll be able to do to sort this out.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #19 received at 10652 <at> debbugs.gnu.org (full text, mbox):

From: Toon Claes <toon <at> tonotdo.com>
To: <10652 <at> debbugs.gnu.org>
Subject: bug#10652 font-lock very slow for C++
Date: Wed, 14 Mar 2012 11:45:14 +0200

[Message part 1 (text/plain, inline)]

 

I'm also having trouble with some cpp files. 

I've got one file
(572 lines, 18560 bytes), that always causes emacs 24 to hang. Emacs
23.3.1 handles this file just fine. 

I am using emacs from git:


commit 6ba3ea4d2625fac8b5fb839f11eeb074d699687e
Author: Christopher
Schmidt <christopher <at> ch.ristopher.com>
Date: Mon Mar 12 01:31:44 2012
+0800

 * ibuffer.el (ibuffer-redisplay): Remove gratuitous error.


When GDB was hanging I stopped the process with GDB, with this
backtrace: 

http://pastebin.com/ssB96ue4 

I'm not familiar with the
emacs source code, but I do not know this is normal. 

If I can help
investigation the problem more in detail, let me know. 

Unfortunately I
am not allowed to share the source file with you. 

Also I've tried to
decrease font-lock-maximum-decoration to 1, but this didn't have effect.


 

[Message part 2 (text/html, inline)]

Message #22 received at 10652 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Toon Claes <toon <at> tonotdo.com>
Cc: 10652 <at> debbugs.gnu.org
Subject: Re: bug#10652: Recursive loop in alloc.c [ Was: font-lock very slow
	for C++ ]
Date: Fri, 16 Mar 2012 10:18:38 +0000

Hello, Emacs and Toon.

I've retitled this bug to clarify what it's about.

-- 
Alan Mackenzie (Nuremberg, Germany).



On Wed, Mar 14, 2012 at 11:45:14AM +0200, Toon Claes wrote:


> I'm also having trouble with some cpp files. 

> I've got one file
> (572 lines, 18560 bytes), that always causes emacs 24 to hang. Emacs
> 23.3.1 handles this file just fine. 

> I am using emacs from git:


> commit 6ba3ea4d2625fac8b5fb839f11eeb074d699687e
> Author: Christopher
> Schmidt <christopher <at> ch.ristopher.com>
> Date: Mon Mar 12 01:31:44 2012
> +0800

>  * ibuffer.el (ibuffer-redisplay): Remove gratuitous error.


> When GDB was hanging I stopped the process with GDB, with this
> backtrace: 

> http://pastebin.com/ssB96ue4 

> I'm not familiar with the
> emacs source code, but I do not know this is normal. 

> If I can help
> investigation the problem more in detail, let me know. 

> Unfortunately I
> am not allowed to share the source file with you. 

> Also I've tried to
> decrease font-lock-maximum-decoration to 1, but this didn't have effect.




> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure

Message #25 received at 10652 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Toon Claes <toon <at> tonotdo.com>, 10652 <at> debbugs.gnu.org
Subject: Re: bug#10652: Recursive loop in alloc.c [ Was: font-lock very slow
	for C++ ]
Date: Fri, 16 Mar 2012 11:34:06 +0100

Alan Mackenzie <acm <at> muc.de> writes:

> I've retitled this bug to clarify what it's about.

That's just the garbage collector, perfectly normal.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #28 received at 10652 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Chong Yidong <cyd <at> gnu.org>
Cc: Helmut Eller <eller.helmut <at> gmail.com>, 10652 <at> debbugs.gnu.org
Subject: Re: bug#10652: 24.0.93; font-lock very slow for C++
Date: Fri, 16 Mar 2012 14:19:37 +0000

Hello, Yidong, Helmut.

On Sun, Feb 26, 2012 at 05:47:25PM +0800, Chong Yidong wrote:
> Helmut Eller <eller.helmut <at> gmail.com> writes:

> > Font lock is extremely slow in this file:

> > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/raw-file/b92c45f2bc75/src/share/vm/runtime/globals.hpp

> > Download the file and open it with emacs -Q globals.hpp.  Then
> > scroll around in the file to see how slow it is.

> I got Emacs into an uninterruptible loop while scrolling through the
> buffer :-(

> Looks like a regression against Emacs 23's CC mode, which handles the
> file just fine.  Alan, could you investigate?  Thanks.

I've just committed revision #107615, which solves the slow scrolling
problem.  Typing "electric" characters (e.g. comma) into the buffer is
still slower than I'd like, but is tolerable.

I don't intend doing any more optimisation before the next pretest (or
release :-).

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #33 received at 10652-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: 10652-done <at> debbugs.gnu.org
Subject: Re: bug#10652: 24.0.93; font-lock very slow for C++
Date: Fri, 16 Mar 2012 14:24:57 +0000

Fixed.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #41 received at 10652 <at> debbugs.gnu.org (full text, mbox):

From: Toon Claes <toon <at> tonotdo.com>
To: Alan Mackenzie <acm <at> muc.de>, <10652 <at> debbugs.gnu.org>
Subject: bug#10652 font-lock very slow for C++
Date: Wed, 28 Mar 2012 09:07:23 +0200

[Message part 1 (text/plain, inline)]

 

Hello Alan, 

Your changes indeed help. 

Still it happens emacs
completely hangs when isearching. So I do not really agree the bug is
fixed. 

I can (but not really allowed to) send you the cpp file which
causes trouble. If you agree to not distribute it? 

Regards, 

Toon 

 

[Message part 2 (text/html, inline)]

Message #44 received at 10652 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Toon Claes <toon <at> tonotdo.com>
Cc: 10652 <at> debbugs.gnu.org
Subject: Re: bug#10652 font-lock very slow for C++
Date: Thu, 29 Mar 2012 09:35:18 +0000

Hi, Toon.

On Wed, Mar 28, 2012 at 09:07:23AM +0200, Toon Claes wrote:


> Hello Alan, 

> Your changes indeed help. 

> Still it happens emacs
> completely hangs when isearching. So I do not really agree the bug is
> fixed. 

Sorry about that!  Can I assume
(i) You've already tried this, starting Emacs with Emacs -Q?
(ii) Youre using the latest version of Emacs 24?

Searching and C++ Mode are, as far as I know, completely orthogonal.
Before going any further, could you please try switching the file into
fundamental mode (with M-x fundamental-mode) and tell me if the search
still hangs.  Thanks!

[ .... ]

> Regards, 

> Toon 

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #47 received at 10652 <at> debbugs.gnu.org (full text, mbox):

From: Toon Claes <toon <at> tonotdo.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: "10652 <at> debbugs.gnu.org" <10652 <at> debbugs.gnu.org>
Subject: Re: bug#10652 font-lock very slow for C++
Date: Thu, 29 Mar 2012 21:46:03 +0200

Hi Alan,

About:
(i) yes I've tried that, emacs -Q didn't make a difference
(ii) I am using emacs from git, commit 2ac37884107bd4e78bb… Should I get it from the bazaar repo?
(iii) I know font-lock has nothing to do with isearch. When I disable font-lock-mode for the buffer, isearch does not hang. So the issue isn't isearch. Sorry I created some confusion in previous mail.

Toon

On 29 Mar 2012, at 11:35, Alan Mackenzie wrote:

> Hi, Toon.
> 
> On Wed, Mar 28, 2012 at 09:07:23AM +0200, Toon Claes wrote:
> 
> 
>> Hello Alan, 
> 
>> Your changes indeed help. 
> 
>> Still it happens emacs
>> completely hangs when isearching. So I do not really agree the bug is
>> fixed. 
> 
> Sorry about that!  Can I assume
> (i) You've already tried this, starting Emacs with Emacs -Q?
> (ii) Youre using the latest version of Emacs 24?
> 
> Searching and C++ Mode are, as far as I know, completely orthogonal.
> Before going any further, could you please try switching the file into
> fundamental mode (with M-x fundamental-mode) and tell me if the search
> still hangs.  Thanks!
> 
> [ .... ]
> 
>> Regards, 
> 
>> Toon 
> 
> -- 
> Alan Mackenzie (Nuremberg, Germany).

Message #50 received at 10652 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Toon Claes <toon <at> tonotdo.com>
Cc: "10652 <at> debbugs.gnu.org" <10652 <at> debbugs.gnu.org>
Subject: Re: bug#10652 font-lock very slow for C++
Date: Thu, 29 Mar 2012 22:00:26 +0000

Hello, Toon.

On Thu, Mar 29, 2012 at 09:46:03PM +0200, Toon Claes wrote:
> Hi Alan,

> About:
> (i) yes I've tried that, emacs -Q didn't make a difference

Worth knowing

> (ii) I am using emacs from git, commit 2ac37884107bd4e78bb… Should I
> get it from the bazaar repo?

I'm not familiar with the git repository.  If the revision is recent
(within the last week or two or three) it should be OK.  I just wanted to
check you weren't using a 6-month old version.

> (iii) I know font-lock has nothing to do with isearch. When I disable
> font-lock-mode for the buffer, isearch does not hang. So the issue
> isn't isearch. Sorry I created some confusion in previous mail.

OK.  What I suspect is that the isearch works fine, then the
fontification hangs before the screen can redisplay.  How long does it
hang for?  Any chance you could perhaps leave it hanging over lunchtime,
or perhaps even overnight to see if it might just be _very_ slow.

Could you perhaps try disabling font-lock, doing the isearch, then
enabling font-lock again.  Does it then still hang, or does it come up
OK?

Lastly, is there anything unusual about your test file.  Perhaps long
regions of text which contain no semicolons or maybe no braces?  Or maybe
hundreds of macro definitions one after the other, something like that?

> Toon

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #53 received at 10652 <at> debbugs.gnu.org (full text, mbox):

From: Toon Claes <toon <at> tonotdo.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 10652 <at> debbugs.gnu.org
Subject: Re: bug#10652 font-lock very slow for C++
Date: Mon, 02 Apr 2012 09:48:12 +0200

[Message part 1 (text/plain, inline)]

 

Hi Alan, 

emacs hangs for hours. Luckily it only used one of my 4
processor cores, so I could leave it loading in the background. 

This
is what I've done: 

Open the file, in c++-mode, and scroll to
end-of-buffer (M->). The mouse cursor starts spinning, but the end of
buffer is not shown. 

When I press C-g three times, the end of the
buffer is shown. The fontification looks correct. 

When I go back to
beginning-of-buffer, same problem. 

When I press M->, M-< several
times, I cannot recover with C-g and I need to kill emacs:-( 

isearch
works fine with font-lock-mode disabled. 

Even, depending on the
position in the buffer, it happens the command M-x font-lock-mode gives
the spinning mouse cursor. Again 3x C-g solves this. 

So I can say
pretty sure, font-lock-mode is causing the "delay". 

I've tested again
with the bazaar version of last friday. 

My test file contains
something like this: 

 int ClassName::MethodAbc(void) 

 { 


SOME_PRETEST_MACRO; 

 return TranslateResult(LibFunctionAbc(m_Member));


 } 

And this repeated for something like 20 times (of course with
different names, and with different parameters). 

The macro is
something like: 

 #define SOME_PRETEST_MACRO if (!Ready()) return -1;


With this test file, I could easily reproduce the problem. 

I hope
this can help investigating the issue. 

Toon 

On 2012-03-30 00:00,
Alan Mackenzie wrote: 

> Hello, Toon.
> 
> On Thu, Mar 29, 2012 at
09:46:03PM +0200, Toon Claes wrote:
> 
>> Hi Alan,
> 
>> About: (i) yes
I've tried that, emacs -Q didn't make a difference
> 
> Worth knowing

 

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.