From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Toon Claes Newsgroups: gmane.emacs.bugs Subject: bug#10652: font-lock very slow for C++ Date: Mon, 02 Apr 2012 09:48:12 +0200 Message-ID: <3cd3c01ead9ed4dc9ceca684516e88d3@tonotdo.com> References: <05ad2fb77a606d40fcdd51af095a5280@tonotdo.com> <20120329093517.GA2961@acm.acm> <79C7C145-A878-4C38-9B5F-95DFC30C68CD@tonotdo.com> <20120329220026.GC2594@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_0054d125467ef90f40bda238c8a1805e" X-Trace: dough.gmane.org 1333352955 26171 80.91.229.3 (2 Apr 2012 07:49:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Apr 2012 07:49:15 +0000 (UTC) Cc: 10652@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 02 09:49:14 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SEc0k-0006P1-D9 for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Apr 2012 09:49:10 +0200 Original-Received: from localhost ([::1]:56192 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SEc0j-000711-Nx for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Apr 2012 03:49:09 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SEc0a-00070c-A4 for bug-gnu-emacs@gnu.org; Mon, 02 Apr 2012 03:49:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SEc0S-0001J7-My for bug-gnu-emacs@gnu.org; Mon, 02 Apr 2012 03:48:59 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38795) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SEc0O-0001IS-Fk; Mon, 02 Apr 2012 03:48:48 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SEc0c-0007ew-4f; Mon, 02 Apr 2012 03:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Toon Claes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Mon, 02 Apr 2012 07:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10652 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 10652-submit@debbugs.gnu.org id=B10652.133335291329400 (code B ref 10652); Mon, 02 Apr 2012 07:49:02 +0000 Original-Received: (at 10652) by debbugs.gnu.org; 2 Apr 2012 07:48:33 +0000 Original-Received: from localhost ([127.0.0.1]:35332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SEc08-0007e7-A2 for submit@debbugs.gnu.org; Mon, 02 Apr 2012 03:48:33 -0400 Original-Received: from web1.futureweb.be ([77.243.237.194]:37073) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SEc04-0007dy-PP for 10652@debbugs.gnu.org; Mon, 02 Apr 2012 03:48:31 -0400 Original-Received: from localhost ([127.0.0.1] helo=tonotdo.com) by web1.futureweb.be with esmtpa (Exim 4.77) (envelope-from ) id 1SEbzo-0002HV-Oh; Mon, 02 Apr 2012 09:48:12 +0200 In-Reply-To: <20120329220026.GC2594@acm.acm> X-Sender: toon@tonotdo.com User-Agent: Roundcube Webmail/0.7.1 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:58462 Archived-At: --=_0054d125467ef90f40bda238c8a1805e Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 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 --=_0054d125467ef90f40bda238c8a1805e Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

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 mo= use 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 fontif= ication 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= =2E

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_M= ember));

    }

 

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
(ii) I am using emacs from git, commi= t 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 doe= s not hang. So the issue isn't isearch. Sorry I created some confusion in p= revious 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

 

 
--=_0054d125467ef90f40bda238c8a1805e--