* bug#10652: 24.0.93; font-lock very slow for C++
@ 2012-01-30 11:15 Helmut Eller
2012-02-26 9:47 ` Chong Yidong
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: Helmut Eller @ 2012-01-30 11:15 UTC (permalink / raw)
To: 10652
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: 24.0.93; font-lock very slow for C++
2012-01-30 11:15 bug#10652: 24.0.93; font-lock very slow for C++ Helmut Eller
@ 2012-02-26 9:47 ` Chong Yidong
2012-03-01 19:36 ` Alan Mackenzie
` (2 more replies)
2012-03-14 9:45 ` bug#10652: " Toon Claes
` (2 subsequent siblings)
3 siblings, 3 replies; 14+ messages in thread
From: Chong Yidong @ 2012-02-26 9:47 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Helmut Eller, 10652
Helmut Eller <eller.helmut@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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: 24.0.93; font-lock very slow for C++
2012-02-26 9:47 ` Chong Yidong
@ 2012-03-01 19:36 ` Alan Mackenzie
2012-03-02 22:27 ` Alan Mackenzie
2012-03-16 14:19 ` Alan Mackenzie
2 siblings, 0 replies; 14+ messages in thread
From: Alan Mackenzie @ 2012-03-01 19:36 UTC (permalink / raw)
To: Chong Yidong; +Cc: Helmut Eller, 10652
Hello Yidong, hello Helmut.
On Sun, Feb 26, 2012 at 05:47:25PM +0800, Chong Yidong wrote:
> Helmut Eller <eller.helmut@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).
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: 24.0.93; font-lock very slow for C++
2012-02-26 9:47 ` Chong Yidong
2012-03-01 19:36 ` Alan Mackenzie
@ 2012-03-02 22:27 ` Alan Mackenzie
2012-03-16 14:19 ` Alan Mackenzie
2 siblings, 0 replies; 14+ messages in thread
From: Alan Mackenzie @ 2012-03-02 22:27 UTC (permalink / raw)
To: Chong Yidong; +Cc: Helmut Eller, 10652
Hello Yidong, hello Helmut.
On Sun, Feb 26, 2012 at 05:47:25PM +0800, Chong Yidong wrote:
> Helmut Eller <eller.helmut@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).
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: font-lock very slow for C++
2012-01-30 11:15 bug#10652: 24.0.93; font-lock very slow for C++ Helmut Eller
2012-02-26 9:47 ` Chong Yidong
@ 2012-03-14 9:45 ` Toon Claes
2012-03-16 10:18 ` bug#10652: Recursive loop in alloc.c [ Was: font-lock very slow for C++ ] Alan Mackenzie
[not found] ` <20120316101838.GB3439@acm.acm>
2012-03-16 14:24 ` bug#10652: 24.0.93; font-lock very slow for C++ Alan Mackenzie
2012-03-28 7:07 ` bug#10652: " Toon Claes
3 siblings, 2 replies; 14+ messages in thread
From: Toon Claes @ 2012-03-14 9:45 UTC (permalink / raw)
To: 10652
[-- Attachment #1: Type: text/plain, Size: 833 bytes --]
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@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.
[-- Attachment #2: Type: text/html, Size: 1117 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: Recursive loop in alloc.c [ Was: font-lock very slow for C++ ]
2012-03-14 9:45 ` bug#10652: " Toon Claes
@ 2012-03-16 10:18 ` Alan Mackenzie
[not found] ` <20120316101838.GB3439@acm.acm>
1 sibling, 0 replies; 14+ messages in thread
From: Alan Mackenzie @ 2012-03-16 10:18 UTC (permalink / raw)
To: Toon Claes; +Cc: 10652
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@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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: Recursive loop in alloc.c [ Was: font-lock very slow for C++ ]
[not found] ` <20120316101838.GB3439@acm.acm>
@ 2012-03-16 10:34 ` Andreas Schwab
0 siblings, 0 replies; 14+ messages in thread
From: Andreas Schwab @ 2012-03-16 10:34 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Toon Claes, 10652
Alan Mackenzie <acm@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: 24.0.93; font-lock very slow for C++
2012-02-26 9:47 ` Chong Yidong
2012-03-01 19:36 ` Alan Mackenzie
2012-03-02 22:27 ` Alan Mackenzie
@ 2012-03-16 14:19 ` Alan Mackenzie
2 siblings, 0 replies; 14+ messages in thread
From: Alan Mackenzie @ 2012-03-16 14:19 UTC (permalink / raw)
To: Chong Yidong; +Cc: Helmut Eller, 10652
Hello, Yidong, Helmut.
On Sun, Feb 26, 2012 at 05:47:25PM +0800, Chong Yidong wrote:
> Helmut Eller <eller.helmut@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).
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: 24.0.93; font-lock very slow for C++
2012-01-30 11:15 bug#10652: 24.0.93; font-lock very slow for C++ Helmut Eller
2012-02-26 9:47 ` Chong Yidong
2012-03-14 9:45 ` bug#10652: " Toon Claes
@ 2012-03-16 14:24 ` Alan Mackenzie
2012-03-28 7:07 ` bug#10652: " Toon Claes
3 siblings, 0 replies; 14+ messages in thread
From: Alan Mackenzie @ 2012-03-16 14:24 UTC (permalink / raw)
To: 10652-done
Fixed.
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: font-lock very slow for C++
2012-01-30 11:15 bug#10652: 24.0.93; font-lock very slow for C++ Helmut Eller
` (2 preceding siblings ...)
2012-03-16 14:24 ` bug#10652: 24.0.93; font-lock very slow for C++ Alan Mackenzie
@ 2012-03-28 7:07 ` Toon Claes
2012-03-29 9:35 ` Alan Mackenzie
3 siblings, 1 reply; 14+ messages in thread
From: Toon Claes @ 2012-03-28 7:07 UTC (permalink / raw)
To: Alan Mackenzie, 10652
[-- Attachment #1: Type: text/plain, Size: 281 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: font-lock very slow for C++
2012-03-28 7:07 ` bug#10652: " Toon Claes
@ 2012-03-29 9:35 ` Alan Mackenzie
2012-03-29 19:46 ` Toon Claes
0 siblings, 1 reply; 14+ messages in thread
From: Alan Mackenzie @ 2012-03-29 9:35 UTC (permalink / raw)
To: Toon Claes; +Cc: 10652
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).
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: font-lock very slow for C++
2012-03-29 9:35 ` Alan Mackenzie
@ 2012-03-29 19:46 ` Toon Claes
2012-03-29 22:00 ` Alan Mackenzie
0 siblings, 1 reply; 14+ messages in thread
From: Toon Claes @ 2012-03-29 19:46 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 10652@debbugs.gnu.org
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).
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: font-lock very slow for C++
2012-03-29 19:46 ` Toon Claes
@ 2012-03-29 22:00 ` Alan Mackenzie
2012-04-02 7:48 ` Toon Claes
0 siblings, 1 reply; 14+ messages in thread
From: Alan Mackenzie @ 2012-03-29 22:00 UTC (permalink / raw)
To: Toon Claes; +Cc: 10652@debbugs.gnu.org
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).
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#10652: font-lock very slow for C++
2012-03-29 22:00 ` Alan Mackenzie
@ 2012-04-02 7:48 ` Toon Claes
0 siblings, 0 replies; 14+ messages in thread
From: Toon Claes @ 2012-04-02 7:48 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 10652
[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 4145 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-04-02 7:48 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-30 11:15 bug#10652: 24.0.93; font-lock very slow for C++ Helmut Eller
2012-02-26 9:47 ` Chong Yidong
2012-03-01 19:36 ` Alan Mackenzie
2012-03-02 22:27 ` Alan Mackenzie
2012-03-16 14:19 ` Alan Mackenzie
2012-03-14 9:45 ` bug#10652: " Toon Claes
2012-03-16 10:18 ` bug#10652: Recursive loop in alloc.c [ Was: font-lock very slow for C++ ] Alan Mackenzie
[not found] ` <20120316101838.GB3439@acm.acm>
2012-03-16 10:34 ` Andreas Schwab
2012-03-16 14:24 ` bug#10652: 24.0.93; font-lock very slow for C++ Alan Mackenzie
2012-03-28 7:07 ` bug#10652: " Toon Claes
2012-03-29 9:35 ` Alan Mackenzie
2012-03-29 19:46 ` Toon Claes
2012-03-29 22:00 ` Alan Mackenzie
2012-04-02 7:48 ` Toon Claes
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).