bug#19846: 25.0.50; Problem with auto-fill-mode and C mode

[Alan Mackenzie]

Hi, Martin.

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

> In article <mailman.19768.1423766347.1147.bug-gnu-emacs@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).