* bug#19846: 25.0.50; Problem with auto-fill-mode and C mode
@ 2015-02-12 18:37 martin rudalics
2015-02-13 17:07 ` Stefan Monnier
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: martin rudalics @ 2015-02-12 18:37 UTC (permalink / raw)
To: 19846
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#19846: 25.0.50; Problem with auto-fill-mode and C mode
2015-02-12 18:37 bug#19846: 25.0.50; Problem with auto-fill-mode and C mode martin rudalics
@ 2015-02-13 17:07 ` Stefan Monnier
[not found] ` <jwv4mqp91vo.fsf-monnier+emacsbugs@gnu.org>
[not found] ` <mailman.19768.1423766347.1147.bug-gnu-emacs@gnu.org>
2 siblings, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2015-02-13 17:07 UTC (permalink / raw)
To: martin rudalics; +Cc: 19846
> '(lambda ()
Please don't quote your lambdas,
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#19846: 25.0.50; Problem with auto-fill-mode and C mode
[not found] ` <jwv4mqp91vo.fsf-monnier+emacsbugs@gnu.org>
@ 2015-02-13 18:27 ` martin rudalics
0 siblings, 0 replies; 11+ messages in thread
From: martin rudalics @ 2015-02-13 18:27 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 19846
>> '(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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#19846: 25.0.50; Problem with auto-fill-mode and C mode
[not found] ` <mailman.19768.1423766347.1147.bug-gnu-emacs@gnu.org>
@ 2015-02-14 11:48 ` Alan Mackenzie
2015-02-14 16:31 ` Alan Mackenzie
2015-02-14 18:21 ` martin rudalics
0 siblings, 2 replies; 11+ messages in thread
From: Alan Mackenzie @ 2015-02-14 11:48 UTC (permalink / raw)
To: 19846
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).
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#19846: 25.0.50; Problem with auto-fill-mode and C mode
2015-02-14 11:48 ` Alan Mackenzie
@ 2015-02-14 16:31 ` Alan Mackenzie
2015-02-14 18:21 ` martin rudalics
1 sibling, 0 replies; 11+ messages in thread
From: Alan Mackenzie @ 2015-02-14 16:31 UTC (permalink / raw)
To: 19846
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).
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#19846: 25.0.50; Problem with auto-fill-mode and C mode
2015-02-14 11:48 ` Alan Mackenzie
2015-02-14 16:31 ` Alan Mackenzie
@ 2015-02-14 18:21 ` martin rudalics
2022-05-01 10:08 ` Lars Ingebrigtsen
1 sibling, 1 reply; 11+ messages in thread
From: martin rudalics @ 2015-02-14 18:21 UTC (permalink / raw)
To: Alan Mackenzie, 19846
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#19846: 25.0.50; Problem with auto-fill-mode and C mode
2015-02-14 18:21 ` martin rudalics
@ 2022-05-01 10:08 ` Lars Ingebrigtsen
2022-05-01 11:35 ` Alan Mackenzie
[not found] ` <Ym5wnNUf/qHOVi9F@ACM>
0 siblings, 2 replies; 11+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-01 10:08 UTC (permalink / raw)
To: martin rudalics; +Cc: Alan Mackenzie, 19846
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#19846: 25.0.50; Problem with auto-fill-mode and C mode
2022-05-01 10:08 ` Lars Ingebrigtsen
@ 2022-05-01 11:35 ` Alan Mackenzie
[not found] ` <Ym5wnNUf/qHOVi9F@ACM>
1 sibling, 0 replies; 11+ messages in thread
From: Alan Mackenzie @ 2022-05-01 11:35 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 19846, acm
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).
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#19846: 25.0.50; Problem with auto-fill-mode and C mode
[not found] ` <Ym5wnNUf/qHOVi9F@ACM>
@ 2022-05-01 11:44 ` Lars Ingebrigtsen
2022-05-01 14:53 ` Alan Mackenzie
0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-01 11:44 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 19846
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#19846: 25.0.50; Problem with auto-fill-mode and C mode
2022-05-01 11:44 ` Lars Ingebrigtsen
@ 2022-05-01 14:53 ` Alan Mackenzie
2022-05-01 14:55 ` Lars Ingebrigtsen
0 siblings, 1 reply; 11+ messages in thread
From: Alan Mackenzie @ 2022-05-01 14:53 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 19846
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).
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#19846: 25.0.50; Problem with auto-fill-mode and C mode
2022-05-01 14:53 ` Alan Mackenzie
@ 2022-05-01 14:55 ` Lars Ingebrigtsen
0 siblings, 0 replies; 11+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-01 14:55 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 19846
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-05-01 14:55 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-12 18:37 bug#19846: 25.0.50; Problem with auto-fill-mode and C mode martin rudalics
2015-02-13 17:07 ` Stefan Monnier
[not found] ` <jwv4mqp91vo.fsf-monnier+emacsbugs@gnu.org>
2015-02-13 18:27 ` martin rudalics
[not found] ` <mailman.19768.1423766347.1147.bug-gnu-emacs@gnu.org>
2015-02-14 11:48 ` Alan Mackenzie
2015-02-14 16:31 ` Alan Mackenzie
2015-02-14 18:21 ` martin rudalics
2022-05-01 10:08 ` Lars Ingebrigtsen
2022-05-01 11:35 ` Alan Mackenzie
[not found] ` <Ym5wnNUf/qHOVi9F@ACM>
2022-05-01 11:44 ` Lars Ingebrigtsen
2022-05-01 14:53 ` Alan Mackenzie
2022-05-01 14:55 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.