GNU bug report logs -
#40052
CC Mode 5.34 (C++//l); cc-mode hangs fontifying src/hotspot/share/runtime/globals.hpp in OpenJDK
Previous Next
Reported by: Nick Gasson <nick.gasson <at> arm.com>
Date: Fri, 13 Mar 2020 14:33:02 UTC
Severity: normal
Done: Alan Mackenzie <acm <at> muc.de>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40052 in the body.
You can then email your comments to 40052 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-cc-mode <at> gnu.org:
bug#40052; Package
cc-mode.
(Fri, 13 Mar 2020 14:33:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Nick Gasson <nick.gasson <at> arm.com>:
New bug report received and forwarded. Copy sent to
bug-cc-mode <at> gnu.org.
(Fri, 13 Mar 2020 14:33:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Package: cc-mode
Open this file with emacs --no-init-file, page down a few times and
Emacs locks up:
http://hg.openjdk.java.net/jdk/jdk/raw-file/29edf1cb3c02/src/hotspot/share/runtime/globals.hpp
Emacs : GNU Emacs 27.0.90 (build 1, aarch64-unknown-linux-gnu, GTK+ Version 3.24.13)
of 2020-03-09
Package: CC Mode 5.34 (C++//l)
Buffer Style: gnu
c-emacs-features: (pps-extended-state col-0-paren posix-char-classes gen-string-delim gen-comment-delim syntax-properties 1-bit)
current state:
==============
(setq
c-basic-offset 2
c-comment-only-line-offset '(0 . 0)
c-indent-comment-alist '((anchored-comment column . 0) (end-block space . 1)
(cpp-end-block space . 2))
c-indent-comments-syntactically-p nil
c-block-comment-prefix ""
c-comment-prefix-regexp '((pike-mode . "//+!?\\|\\**") (awk-mode . "#+")
(other . "//+\\|\\**"))
c-doc-comment-style '((java-mode . javadoc) (pike-mode . autodoc) (c-mode . gtkdoc)
(c++-mode . gtkdoc))
c-cleanup-list '(scope-operator)
c-hanging-braces-alist '((substatement-open before after) (arglist-cont-nonempty))
c-hanging-colons-alist nil
c-hanging-semi&comma-criteria '(c-semi&comma-inside-parenlist)
c-backslash-column 48
c-backslash-max-column 72
c-special-indent-hook '(c-gnu-impose-minimum)
c-label-minimum-indentation 1
c-offsets-alist '((inexpr-class . +)
(inexpr-statement . +)
(lambda-intro-cont . +)
(inlambda . 0)
(template-args-cont c-lineup-template-args +)
(incomposition . +)
(inmodule . +)
(innamespace . +)
(inextern-lang . +)
(composition-close . 0)
(module-close . 0)
(namespace-close . 0)
(extern-lang-close . 0)
(composition-open . 0)
(module-open . 0)
(namespace-open . 0)
(extern-lang-open . 0)
(objc-method-call-cont
c-lineup-ObjC-method-call-colons
c-lineup-ObjC-method-call
+
)
(objc-method-args-cont . c-lineup-ObjC-method-args)
(objc-method-intro . [0])
(friend . 0)
(cpp-define-intro c-lineup-cpp-define +)
(cpp-macro-cont . +)
(cpp-macro . [0])
(inclass . +)
(stream-op . c-lineup-streamop)
(arglist-cont-nonempty c-lineup-gcc-asm-reg c-lineup-arglist)
(arglist-cont c-lineup-gcc-asm-reg 0)
(comment-intro c-lineup-knr-region-comment c-lineup-comment)
(catch-clause . 0)
(else-clause . 0)
(do-while-closure . 0)
(access-label . -)
(case-label . 0)
(substatement . +)
(statement-case-intro . +)
(statement . 0)
(brace-entry-open . 0)
(brace-list-entry . 0)
(brace-list-close . 0)
(block-close . 0)
(block-open . 0)
(inher-cont . c-lineup-multi-inher)
(inher-intro . +)
(member-init-cont . c-lineup-multi-inher)
(member-init-intro . +)
(annotation-var-cont . +)
(annotation-top-cont . 0)
(topmost-intro . 0)
(knr-argdecl . 0)
(func-decl-cont . +)
(inline-close . 0)
(class-close . 0)
(class-open . 0)
(defun-block-intro . +)
(defun-close . 0)
(defun-open . 0)
(c . c-lineup-C-comments)
(string . c-lineup-dont-change)
(topmost-intro-cont
first
c-lineup-topmost-intro-cont
c-lineup-gnu-DEFUN-intro-cont
)
(brace-list-intro . +)
(brace-list-open . +)
(inline-open . 0)
(arglist-close . 0)
(arglist-intro . +)
(statement-cont . +)
(statement-case-open . +)
(label . 0)
(substatement-label . 0)
(substatement-open . +)
(knr-argdecl-intro . 5)
(statement-block-intro . +)
)
c-buffer-is-cc-mode 'c++-mode
c-tab-always-indent t
c-syntactic-indentation t
c-syntactic-indentation-in-macros t
c-ignore-auto-fill '(string cpp code)
c-auto-align-backslashes t
c-backspace-function 'backward-delete-char-untabify
c-delete-function 'delete-char
c-electric-pound-behavior nil
c-default-style '((java-mode . "java") (awk-mode . "awk") (other . "gnu"))
c-enable-xemacs-performance-kludge-p nil
c-old-style-variable-behavior nil
defun-prompt-regexp nil
tab-width 8
comment-column 32
parse-sexp-ignore-comments t
parse-sexp-lookup-properties t
auto-fill-function nil
comment-multi-line t
comment-start-skip "\\(//+\\|/\\*+\\)\\s *"
fill-prefix nil
fill-column 72
paragraph-start "[ ]*\\(//+\\|\\**\\)[ ]*$\\|^\f"
adaptive-fill-mode t
adaptive-fill-regexp "[ ]*\\(//+\\|\\**\\)[ ]*\\([ ]*\\([-–!|#%;>*·•‣⁃◦]+[ ]*\\)*\\)"
)
Information forwarded
to
bug-cc-mode <at> gnu.org:
bug#40052; Package
cc-mode.
(Thu, 16 Apr 2020 19:49:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 40052 <at> debbugs.gnu.org (full text, mbox):
Hello, Nick.
On Fri, Mar 13, 2020 at 18:02:03 +0800, Nick Gasson wrote:
> Package: cc-mode
> Open this file with emacs --no-init-file, page down a few times and
> Emacs locks up:
> http://hg.openjdk.java.net/jdk/jdk/raw-file/29edf1cb3c02/src/hotspot/share/runtime/globals.hpp
Thanks for taking the trouble to report this bug. It has been a tough
one to crack.
When I tried it, my Emacs slowed down to a crawl rather than locking up
completely. I'm assuming that this would have been the case on your
machine, too.
Most obviously, there is a huge macro in globals.hpp. Although there
are some optimisations in CC Mode for large macros, they are incomplete,
so working on or around such a macro can be slow.
What is taking most of the time is a CC Mode function which goes back
over syntactic whitespace (spaces, tabs, comments, and when starting
outside of a macro, that macro).
This hits a bug in Emacs where it allows the backward search operation
for a comment start, when point is at the beginning of the line
following an escaped newline. Such a position can never be an end of a
comment in C++.
However, this search backwards for a comment start is being done many
thousand times in globals.hpp because of the consecutive escaped
newlines.
The fix to Emacs won't actually be getting released until Emacs 28, so
in the meantime, please try the following patch. The files to patch are
in directory ...../emacs/lisp/progmodes. After patching them, please
byte compile the two files. (If you want any help in patching or byte
compiling, feel free to send me private email.)
In my timings, scrolling with the patch applied is about four times as
fast as without it. I've also included a correction to a bug about
"regexp stack overflow" which happened when one tried actually to edit
this buffer. Clearly this speed is still not fast enough, but it might
be bearable at a pinch. I will carry on trying to speed it up.
Please let me know how you get on with the patch. Thanks!
diff -r 99da14f7dde7 cc-engine.el
--- a/cc-engine.el Sun Mar 08 15:07:06 2020 +0000
+++ b/cc-engine.el Thu Apr 16 19:33:34 2020 +0000
@@ -1648,6 +1648,16 @@
(forward-char 2)
t))))
+(defmacro c-forward-comment-minus-1 ()
+ "Call (forward-comment -1), taking care of escaped newlines.
+Return the result of `forward-comment' if it gets called, nil otherwise."
+ `(when
+ (or (not comment-end-can-be-escaped)
+ (progn (skip-chars-backward " \t\n")
+ (not (and (eq (char-after) ?\n)
+ (eq (char-before) ?\\)))))
+ (forward-comment -1)))
+
(defun c-backward-single-comment ()
"Move backward past whitespace and the closest preceding comment, if any.
Return t if a comment was found, nil otherwise. In either case, the
@@ -1681,12 +1691,12 @@
;; same line.
(re-search-forward "\\=\\s *[\n\r]" start t)
- (if (if (forward-comment -1)
+ (if (if (c-forward-comment-minus-1)
(if (eolp)
;; If forward-comment above succeeded and we're at eol
;; then the newline we moved over above didn't end a
;; line comment, so we give it another go.
- (forward-comment -1)
+ (c-forward-comment-minus-1)
t))
;; Emacs <= 20 and XEmacs move back over the closer of a
@@ -1715,7 +1725,7 @@
(if (let (moved-comment)
(while
- (and (not (setq moved-comment (forward-comment -1)))
+ (and (not (setq moved-comment (c-forward-comment-minus-1)))
;; Cope specifically with ^M^J here -
;; forward-comment sometimes gets stuck after ^Ms,
;; sometimes after ^M^J.
diff -r 99da14f7dde7 cc-mode.el
--- a/cc-mode.el Sun Mar 08 15:07:06 2020 +0000
+++ b/cc-mode.el Thu Apr 16 19:33:34 2020 +0000
@@ -1413,7 +1413,7 @@
;; Move to end of logical line (as it will be after the change, or as it
;; was before unescaping a NL.)
- (re-search-forward "\\(\\\\\\(.\\|\n\\)\\|[^\\\n\r]\\)*" nil t)
+ (re-search-forward "\\(?:\\\\\\(?:.\\|\n\\)\\|[^\\\n\r]\\)*" nil t)
;; We're at an EOLL or point-max.
(if (equal (c-get-char-property (point) 'syntax-table) '(15))
(if (memq (char-after) '(?\n ?\r))
@@ -1521,7 +1521,7 @@
(progn
(goto-char (min (1+ end) ; 1+, in case a NL has become escaped.
(point-max)))
- (re-search-forward "\\(\\\\\\(.\\|\n\\)\\|[^\\\n\r]\\)*"
+ (re-search-forward "\\(?:\\\\\\(?:.\\|\n\\)\\|[^\\\n\r]\\)*"
nil t)
(point))
c-new-END))
@@ -1602,8 +1602,8 @@
(c-beginning-of-macro))))
(goto-char (1+ end)) ; After the \
;; Search forward for EOLL
- (setq lim (re-search-forward "\\(\\\\\\(.\\|\n\\)\\|[^\\\n\r]\\)*"
- nil t))
+ (setq lim (re-search-forward "\\(?:\\\\\\(?:.\\|\n\\)\\|[^\\\n\r]\\)*"
+ nil t))
(goto-char (1+ end))
(when (c-search-forward-char-property-with-value-on-char
'syntax-table '(15) ?\" lim)
> Emacs : GNU Emacs 27.0.90 (build 1, aarch64-unknown-linux-gnu, GTK+ Version 3.24.13)
> of 2020-03-09
> Package: CC Mode 5.34 (C++//l)
> Buffer Style: gnu
> c-emacs-features: (pps-extended-state col-0-paren posix-char-classes gen-string-delim gen-comment-delim syntax-properties 1-bit)
[ CC Mode state dump snipped, but appreciated. ]
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-cc-mode <at> gnu.org:
bug#40052; Package
cc-mode.
(Fri, 17 Apr 2020 05:35:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 40052 <at> debbugs.gnu.org (full text, mbox):
>
> In my timings, scrolling with the patch applied is about four times as
> fast as without it. I've also included a correction to a bug about
> "regexp stack overflow" which happened when one tried actually to edit
> this buffer. Clearly this speed is still not fast enough, but it might
> be bearable at a pinch. I will carry on trying to speed it up.
>
I applied this patch and it makes a huge difference. It's still a little
slow as you say but it's usable now. Thanks a lot!
Nick
Information forwarded
to
bug-cc-mode <at> gnu.org:
bug#40052; Package
cc-mode.
(Sat, 18 Apr 2020 16:52:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 40052 <at> debbugs.gnu.org (full text, mbox):
Hello, Nick.
On Fri, Apr 17, 2020 at 13:15:49 +0800, Nick Gasson wrote:
> > In my timings, scrolling with the patch applied is about four times as
> > fast as without it. I've also included a correction to a bug about
> > "regexp stack overflow" which happened when one tried actually to edit
> > this buffer. Clearly this speed is still not fast enough, but it might
> > be bearable at a pinch. I will carry on trying to speed it up.
> I applied this patch and it makes a huge difference. It's still a little
> slow as you say but it's usable now. Thanks a lot!
OK, thanks. I've had another look into CC Mode, and found a bug in the
handling of its macro cache. It isn't saving the position of the end of
the macro, hence is doing too much scanning.
I've fixed this in the following patch, which gives another factor of ~5
speedup in the scrolling. Please remove the previous patch before
applying this new one.
However, the scrolling still gets sluggish towards the end of
globals.hpp. This is because CC Mode's function which goes back to the
beginning of a statement is scanning back over the entire macro. It
basically looks for semicolons or closing braces (at top level) and
there are none in the huge macro. I tried creating a variant of
globals.hpp, where each "function call" was terminated by a semicolon.
The sluggishness was entirely fixed. This is largely theoretical, as I
assume you have no control over the contents of globals.hpp.
Anyhow, here is the patch. Please let me know if there are still
problems with it. Thanks!
diff -r 99da14f7dde7 cc-engine.el
--- a/cc-engine.el Sun Mar 08 15:07:06 2020 +0000
+++ b/cc-engine.el Sat Apr 18 09:04:42 2020 +0000
@@ -412,7 +412,7 @@
(when (and (car c-macro-cache)
(> (point) (car c-macro-cache)) ; in case we have a
; zero-sized region.
- (not (eq (char-before (1- (point))) ?\\)))
+ (not lim))
(setcdr c-macro-cache (point))
(setq c-macro-cache-syntactic nil)))))))
@@ -1648,6 +1648,21 @@
(forward-char 2)
t))))
+(defmacro c-forward-comment-minus-1 ()
+ "Call (forward-comment -1), taking care of escaped newlines.
+Return the result of `forward-comment' if it gets called, nil otherwise."
+ `(if (not comment-end-can-be-escaped)
+ (forward-comment -1)
+ (when (and (< (skip-syntax-backward " >") 0)
+ (eq (char-after) ?\n))
+ (forward-char))
+ (cond
+ ((and (eq (char-before) ?\n)
+ (eq (char-before (1- (point))) ?\\))
+ (backward-char)
+ nil)
+ (t (forward-comment -1)))))
+
(defun c-backward-single-comment ()
"Move backward past whitespace and the closest preceding comment, if any.
Return t if a comment was found, nil otherwise. In either case, the
@@ -1681,12 +1696,12 @@
;; same line.
(re-search-forward "\\=\\s *[\n\r]" start t)
- (if (if (forward-comment -1)
+ (if (if (c-forward-comment-minus-1)
(if (eolp)
;; If forward-comment above succeeded and we're at eol
;; then the newline we moved over above didn't end a
;; line comment, so we give it another go.
- (forward-comment -1)
+ (c-forward-comment-minus-1)
t))
;; Emacs <= 20 and XEmacs move back over the closer of a
@@ -1715,7 +1730,7 @@
(if (let (moved-comment)
(while
- (and (not (setq moved-comment (forward-comment -1)))
+ (and (not (setq moved-comment (c-forward-comment-minus-1)))
;; Cope specifically with ^M^J here -
;; forward-comment sometimes gets stuck after ^Ms,
;; sometimes after ^M^J.
diff -r 99da14f7dde7 cc-mode.el
--- a/cc-mode.el Sun Mar 08 15:07:06 2020 +0000
+++ b/cc-mode.el Sat Apr 18 09:04:42 2020 +0000
@@ -1413,7 +1413,7 @@
;; Move to end of logical line (as it will be after the change, or as it
;; was before unescaping a NL.)
- (re-search-forward "\\(\\\\\\(.\\|\n\\)\\|[^\\\n\r]\\)*" nil t)
+ (re-search-forward "\\(?:\\\\\\(?:.\\|\n\\)\\|[^\\\n\r]\\)*" nil t)
;; We're at an EOLL or point-max.
(if (equal (c-get-char-property (point) 'syntax-table) '(15))
(if (memq (char-after) '(?\n ?\r))
@@ -1521,7 +1521,7 @@
(progn
(goto-char (min (1+ end) ; 1+, in case a NL has become escaped.
(point-max)))
- (re-search-forward "\\(\\\\\\(.\\|\n\\)\\|[^\\\n\r]\\)*"
+ (re-search-forward "\\(?:\\\\\\(?:.\\|\n\\)\\|[^\\\n\r]\\)*"
nil t)
(point))
c-new-END))
@@ -1602,8 +1602,8 @@
(c-beginning-of-macro))))
(goto-char (1+ end)) ; After the \
;; Search forward for EOLL
- (setq lim (re-search-forward "\\(\\\\\\(.\\|\n\\)\\|[^\\\n\r]\\)*"
- nil t))
+ (setq lim (re-search-forward "\\(?:\\\\\\(?:.\\|\n\\)\\|[^\\\n\r]\\)*"
+ nil t))
(goto-char (1+ end))
(when (c-search-forward-char-property-with-value-on-char
'syntax-table '(15) ?\" lim)
> Nick
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-cc-mode <at> gnu.org:
bug#40052; Package
cc-mode.
(Wed, 22 Apr 2020 05:08:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 40052 <at> debbugs.gnu.org (full text, mbox):
>
> OK, thanks. I've had another look into CC Mode, and found a bug in the
> handling of its macro cache. It isn't saving the position of the end of
> the macro, hence is doing too much scanning.
>
> I've fixed this in the following patch, which gives another factor of ~5
> speedup in the scrolling. Please remove the previous patch before
> applying this new one.
>
> However, the scrolling still gets sluggish towards the end of
> globals.hpp. This is because CC Mode's function which goes back to the
> beginning of a statement is scanning back over the entire macro. It
> basically looks for semicolons or closing braces (at top level) and
> there are none in the huge macro. I tried creating a variant of
> globals.hpp, where each "function call" was terminated by a semicolon.
> The sluggishness was entirely fixed. This is largely theoretical, as I
> assume you have no control over the contents of globals.hpp.
>
> Anyhow, here is the patch. Please let me know if there are still
> problems with it. Thanks!
>
Hi Alan,
I tried the second patch and it's working well. Thanks again.
There was some discussion of getting rid of the giant macro on the
OpenJDK mailing list. That's when I realised several other people had
the same problem opening that file in Emacs.
https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-March/041088.html
Nick
Reply sent
to
Alan Mackenzie <acm <at> muc.de>:
You have taken responsibility.
(Fri, 15 May 2020 19:45:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Nick Gasson <nick.gasson <at> arm.com>:
bug acknowledged by developer.
(Fri, 15 May 2020 19:45:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 40052-done <at> debbugs.gnu.org (full text, mbox):
Hello, Nick.
On Wed, Apr 22, 2020 at 12:11:18 +0800, Nick Gasson wrote:
> > OK, thanks. I've had another look into CC Mode, and found a bug in the
> > handling of its macro cache. It isn't saving the position of the end of
> > the macro, hence is doing too much scanning.
> > I've fixed this in the following patch, which gives another factor of ~5
> > speedup in the scrolling. Please remove the previous patch before
> > applying this new one.
> > However, the scrolling still gets sluggish towards the end of
> > globals.hpp. This is because CC Mode's function which goes back to the
> > beginning of a statement is scanning back over the entire macro. It
> > basically looks for semicolons or closing braces (at top level) and
> > there are none in the huge macro. I tried creating a variant of
> > globals.hpp, where each "function call" was terminated by a semicolon.
> > The sluggishness was entirely fixed. This is largely theoretical, as I
> > assume you have no control over the contents of globals.hpp.
> > Anyhow, here is the patch. Please let me know if there are still
> > problems with it. Thanks!
> Hi Alan,
> I tried the second patch and it's working well. Thanks again.
Thanks for the testing. I've finally got around to committing it into
Emacs, but sadly the cut-off for Emacs 27 has long past, so the fix
won't be seeing the light of day until Emacs 28 (or the next stand-alone
CC Mode, of course).
> There was some discussion of getting rid of the giant macro on the
> OpenJDK mailing list. That's when I realised several other people had
> the same problem opening that file in Emacs.
> https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-March/041088.html
Well, without that macro, a bug might have remained unfixed for a
long(er) time, but if it were up to me, I'd want to reduce the size of
that macro, too. ;-)
> Nick
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-cc-mode <at> gnu.org:
bug#40052; Package
cc-mode.
(Fri, 15 May 2020 21:08:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 40052 <at> debbugs.gnu.org (full text, mbox):
[ Just a side, question, really. ]
Hi Alan,
> This hits a bug in Emacs where it allows the backward search operation
> for a comment start, when point is at the beginning of the line
> following an escaped newline. Such a position can never be an end of a
> comment in C++.
This problems seems to apply to `c-mode` as much as to `c++-mode`, so
I took a quick look to see if it also affects `sm-c-mode` (tested with
Emacs-26) and it seems not to be the case.
(At least, scrolling and editing this file in `sm-c-mode` is not
unusably slow (tho it is a bit sluggish, especially editing, which is
slowed down by `sm-c-mode`s feature that re-aligns the trailing
backslashes after each edit)).
> The fix to Emacs won't actually be getting released until Emacs 28, so
> in the meantime, please try the following patch. The files to patch are
This makes it sound like it's related to a bug in the C code.
Is it something you already fixed? Is it the new
`comment-end-can-be-escaped` thingy?
I understand that it could speed things up here, but at the same time
"LFs which don't end a comment" are the rule rather than the exception,
so if it's a performance problem for those backslash-escaped LFs, why
doesn't it also affect all the other LFs?
Stefan
Information forwarded
to
bug-cc-mode <at> gnu.org:
bug#40052; Package
cc-mode.
(Sat, 16 May 2020 09:08:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 40052 <at> debbugs.gnu.org (full text, mbox):
Hello, Stefan.
On Fri, May 15, 2020 at 17:07:28 -0400, Stefan Monnier wrote:
> [ Just a side, question, really. ]
> Hi Alan,
> > This hits a bug in Emacs where it allows the backward search operation
> > for a comment start, when point is at the beginning of the line
> > following an escaped newline. Such a position can never be an end of a
> > comment in C++.
> This problems seems to apply to `c-mode` as much as to `c++-mode`, so
> I took a quick look to see if it also affects `sm-c-mode` (tested with
> Emacs-26) and it seems not to be the case.
> (At least, scrolling and editing this file in `sm-c-mode` is not
> unusably slow (tho it is a bit sluggish, especially editing, which is
> slowed down by `sm-c-mode`s feature that re-aligns the trailing
> backslashes after each edit)).
> > The fix to Emacs won't actually be getting released until Emacs 28, so
> > in the meantime, please try the following patch. The files to patch are
> This makes it sound like it's related to a bug in the C code.
> Is it something you already fixed? Is it the new
> `comment-end-can-be-escaped` thingy?
comment-end-can-be-escaped was actually introduced in Emacs 25, so I
think it counts as "fairly new" rather than "new". ;-)
It was a bug in syntax.c in the use of comment-end-can-be-escaped, and
got fixed by commit 22ba04742072098be60ec223ed2e97fa9a09b045, Date:
Thu Apr 16 17:01:14 2020 +0000, "(forward-comment -n): escaped newline
is sometimes NOT end of comment". The code now tests that flag in the
backward direction as well as the forward direction.
> I understand that it could speed things up here, but at the same time
> "LFs which don't end a comment" are the rule rather than the exception,
> so if it's a performance problem for those backslash-escaped LFs, why
> doesn't it also affect all the other LFs?
What was happening was backward_comment was searching back over the
entire long macro for the beginning of a comment, and was doing so
repeatedly. It might be interesting to try sm-c-mode on Nick Gasson's
file without the above patch to syntax.c.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-cc-mode <at> gnu.org:
bug#40052; Package
cc-mode.
(Sat, 16 May 2020 13:23:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 40052 <at> debbugs.gnu.org (full text, mbox):
> What was happening was backward_comment was searching back over the
> entire long macro for the beginning of a comment, and was doing so
> repeatedly. It might be interesting to try sm-c-mode on Nick Gasson's
> file without the above patch to syntax.c.
That's what I did, that why I mentioned that I tested it with Emacs-26.
Stefan
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 14 Jun 2020 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 329 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.