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

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

[martin rudalics]

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.

In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
  of 2015-02-12 on MACHNO
Repository revision: da726ad0c6177a3442a374a135f40a24945d362c
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
  `configure --prefix=/c/emacs-git/trunk --enable-checking=yes
  --enable-check-lisp-object-type=yes 'CFLAGS=-O0 -g3''

martin

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

[Stefan Monnier]

>  '(lambda ()

Please don't quote your lambdas,


        Stefan

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

[martin rudalics]

 >>   '(lambda ()
 >
 > Please don't quote your lambdas,

Indeed.  15 years old .emacs code, maybe 20.  I didn't even recall what
`auto-fill-mode' does.

Can you reproduce the issue?

martin

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

[Alan Mackenzie]

Hi, Martin.

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.

I don't see the difference between 24.3 and current master.  On both of
them, the behaviour is the same.  The spaces get inserted normally, up
to column 72, then the display freezes.  Some long while later (several
minutes), the display catches up again.  This is with point in column
~500.  (Both of my Emacs builds were with optimisation and without
debugging info.  Your build was without and with.)

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.

> In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
>  of 2015-02-12 on MACHNO
> Repository revision: da726ad0c6177a3442a374a135f40a24945d362c
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> Configured using:
>  `configure --prefix=/c/emacs-git/trunk --enable-checking=yes
>  --enable-check-lisp-object-type=yes 'CFLAGS=-O0 -g3''

Incidentally, that doc string

  If this variable is t, Emacs asks the window manager to give the frame
  intermediately its normal size whenever changing from a full-height or
  full-width state to the fully maximized one and vice versa.

doesn't read well.  The "intermediately" in that position isn't English!
Perhaps something like the following would be better:

If this variable is t, Emacs first asks the window manager to give the
frame its normal size, and only then the final state, whenever changing
from a full-height or full-width state to the fully maximized one and vice
versa.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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).

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

[martin rudalics]

 > I don't see the difference between 24.3 and current master.  On both of
 > them, the behaviour is the same.

You're right.

 > The spaces get inserted normally, up
 > to column 72, then the display freezes.  Some long while later (several
 > minutes), the display catches up again.  This is with point in column
 > ~500.  (Both of my Emacs builds were with optimisation and without
 > debugging info.  Your build was without and with.)

Here the impact is felt immediately, probably because of the way I build
Emacs.  Inserting 72 spaces doesn't make much sense anyway, so this is
not what's bothering me.  But here inserting _any_ character with auto
filling turned on is a pain.  I'm usually typing 2 to 3 characters ahead
of what I see on screen.

I'll now revise the way I build.  If this cures the problem, let's not
bother too much about the column 72 problem.

 > Incidentally, that doc string
 >
 >    If this variable is t, Emacs asks the window manager to give the frame
 >    intermediately its normal size whenever changing from a full-height or
 >    full-width state to the fully maximized one and vice versa.
 >
 > doesn't read well.  The "intermediately" in that position isn't English!
 > Perhaps something like the following would be better:
 >
 > If this variable is t, Emacs first asks the window manager to give the
 > frame its normal size, and only then the final state, whenever changing
 > from a full-height or full-width state to the fully maximized one and vice
 > versa.

If nothing else I at least found a way to get my doc-strings fixed ;-)

Thanks, martin

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

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

> Here the impact is felt immediately, probably because of the way I build
> Emacs.  Inserting 72 spaces doesn't make much sense anyway, so this is
> not what's bothering me.  But here inserting _any_ character with auto
> filling turned on is a pain.  I'm usually typing 2 to 3 characters ahead
> of what I see on screen.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I tried reproducing this, but inserting characters normally in that doc
string seems to be quite speedy.  It's not until I have about two
hundred spaces at the start of the line that I start seeing hangs.

Are you still seeing these issues in recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Alan Mackenzie]

Hello, Lars.

On Sun, May 01, 2022 at 12:08:58 +0200, Lars Ingebrigtsen wrote:
> martin rudalics <rudalics@gmx.at> writes:

> > Here the impact is felt immediately, probably because of the way I build
> > Emacs.  Inserting 72 spaces doesn't make much sense anyway, so this is
> > not what's bothering me.  But here inserting _any_ character with auto
> > filling turned on is a pain.  I'm usually typing 2 to 3 characters ahead
> > of what I see on screen.

> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)

> I tried reproducing this, but inserting characters normally in that doc
> string seems to be quite speedy.  It's not until I have about two
> hundred spaces at the start of the line that I start seeing hangs.

You've got a fast machine, perhaps.  :-)

> Are you still seeing these issues in recent Emacs versions?

I still see them.  What's more, I know exactly what's causing the hangs.

In forward-paragraph, a regular expression is formed by concatenating
the major mode's paragraph-start and paragraph-separate with a few other
things.  In CC Mode (at least), this gives rise to ill-formed regexps
with adjacent sub-expressions which each can match the empty string, or
arbitrary numbers of spaces.

When there fails to be a match, the regexp engine tries in every
possible way to find a match, and thus failing to find one takes a long
time.

I started work on a library to fix ill-formed regexps in 2015, and after
a long gap, recently re-started work on it.  Although there is still
quite a bit to do on it, I can see my way to finishing it.  This would
fix the cause of the bug properly.  Perhaps I may be able to make the
current state available on a git branch under scratch "soon".

So, can you leave this bug open, please?

> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> In forward-paragraph, a regular expression is formed by concatenating
> the major mode's paragraph-start and paragraph-separate with a few other
> things.  In CC Mode (at least), this gives rise to ill-formed regexps
> with adjacent sub-expressions which each can match the empty string, or
> arbitrary numbers of spaces.

Ah, so this is basically a variation on bug#19873?

> So, can you leave this bug open, please?

Sure.  Should it be merged with 19873?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Alan Mackenzie]

Hello, Lars.

On Sun, May 01, 2022 at 13:44:49 +0200, Lars Ingebrigtsen wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > In forward-paragraph, a regular expression is formed by concatenating
> > the major mode's paragraph-start and paragraph-separate with a few other
> > things.  In CC Mode (at least), this gives rise to ill-formed regexps
> > with adjacent sub-expressions which each can match the empty string, or
> > arbitrary numbers of spaces.

> Ah, so this is basically a variation on bug#19873?

> > So, can you leave this bug open, please?

> Sure.  Should it be merged with 19873?

Thanks!  It should indeed be merged with 19873, yes.

> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> Thanks!  It should indeed be merged with 19873, yes.

OK; now done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no