GNU bug report logs - #19846
25.0.50; Problem with auto-fill-mode and C mode

Previous Next

Packages: emacs, cc-mode;

Reported by: martin rudalics <rudalics <at> gmx.at>

Date: Thu, 12 Feb 2015 18:39:01 UTC

Severity: normal

Merged with 19873

Found in version 25.0.50

Full log


View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: 19846 <at> debbugs.gnu.org
Cc: martin rudalics <rudalics <at> gmx.at>
Subject: bug#19846: 25.0.50; Problem with auto-fill-mode and C mode
Date: Sat, 14 Feb 2015 16:31:09 +0000
Hi, Martin.

On Sat, Feb 14, 2015 at 11:48:37AM -0000, Alan Mackenzie wrote:

> In article <mailman.19768.1423766347.1147.bug-gnu-emacs <at> gnu.org> you wrote:
> > With current trunk/master and emacs -Q evaluate the following form

> > (add-hook
> >  'c-mode-hook
> >  '(lambda ()
> >     (turn-on-auto-fill)
> >     (set (make-local-variable 'fill-column) 72)))

> > and visit ~/src/xterm.c.  Go to the end of that file, move a few lines
> > backwards so that point is at the beginning of some non-empty line
> > within the doc-string of `x-frame-normalize-before-maximize' (which is
> > coded as a C comment).  Now keep the SPC key pressed.  Here Emacs
> > consumes the entire available CPU and eventually redisplay gets stuck
> > completely.  This used to work without problems in Emacs 24.3.

> A quick use of the profiler shows that forward-paragraph is taking ~87%
> of the total CPU.  There'll be a reason for this.  I'll have a look at it.

I think I've found it.  In foward-paragraph (paragraphs.el) L+37,
sp-parstat is bound as follows:

    (sp-parstart (concat "^[ \t]*\\(?:" parstart "\\|" parsep "\\)"))

, where parstart and parsep are, basically, paragraph-start and
paragraph-separate.

In CC Mode, paragraph-s{tart,eparate} both start with "[ \t]*".  So when
a regexp search for sp-parstart is done on a non-matching line beginning
with spaces, there will be a lot of alternative ways for the regexp
engine to attempt to match the spaces before finally giving up on the
line.

The optimal solution to the bug would involve intelligently combining
parstart and parsep into a safe regexp.  I don't know how to do this
(suggestions welcome).

The alternative seems to be to search for parstart and parsep separately
inside an `or' form.

Any thoughts?

> > martin

-- 
Alan Mackenzie (Nuremberg, Germany).




This bug report was last modified 3 years and 44 days ago.

Previous Next


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