* Huge {...} blocks in C/C++ again
@ 2013-10-14 16:57 Dmitry Antipov
2013-10-18 20:18 ` Alan Mackenzie
2013-10-23 21:00 ` Alan Mackenzie
0 siblings, 2 replies; 4+ messages in thread
From: Dmitry Antipov @ 2013-10-14 16:57 UTC (permalink / raw)
To: Emacs development discussions; +Cc: Alan Mackenzie
[-- Attachment #1: Type: text/plain, Size: 471 bytes --]
An issue from:
https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00483.html
is exactly reproduced on this header from LLVM project, most probably
due to huge
#ifdef __cplusplus
extern "C" {
#endif
/* a lot of things */
#ifdef __cplusplus
} // extern "C"
#endif
block - a lot of things between top-level { and } hangs everything,
without a chance to quit with C-g.
To reproduce, just do 'emacs -Q linux_syscall_hooks.h' and scroll ~1/2 of buffer.
Dmitry
[-- Attachment #2: linux_syscall_hooks.h.xz --]
[-- Type: application/x-xz, Size: 17628 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Huge {...} blocks in C/C++ again
2013-10-14 16:57 Huge {...} blocks in C/C++ again Dmitry Antipov
@ 2013-10-18 20:18 ` Alan Mackenzie
2013-10-23 21:00 ` Alan Mackenzie
1 sibling, 0 replies; 4+ messages in thread
From: Alan Mackenzie @ 2013-10-18 20:18 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: Emacs development discussions
Hi, Dmitry.
On Mon, Oct 14, 2013 at 08:57:53PM +0400, Dmitry Antipov wrote:
> An issue from:
> https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00483.html
> is exactly reproduced on this header from LLVM project, most probably
> due to huge
I'm not convinced about that "most probably". ;-)
> #ifdef __cplusplus
> extern "C" {
> #endif
> /* a lot of things */
> #ifdef __cplusplus
> } // extern "C"
> #endif
> block - a lot of things between top-level { and } hangs everything,
> without a chance to quit with C-g.
> To reproduce, just do 'emacs -Q linux_syscall_hooks.h' and scroll ~1/2 of buffer.
First investigative results: the problem occurs only with the CC Mode
embedded in Emacs. With the standalone CC Mode (available at
<http://cc-mode.sourceforge.net/release.php>) the file works without
problems.
I've run ELP on the scrolling, and there seems to be a well defined call
stack causing the problem, with c-syntactic-skip-backwards being where
it's hanging.
I'll see if I can debug this over the weekend.
> Dmitry
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Huge {...} blocks in C/C++ again
2013-10-14 16:57 Huge {...} blocks in C/C++ again Dmitry Antipov
2013-10-18 20:18 ` Alan Mackenzie
@ 2013-10-23 21:00 ` Alan Mackenzie
2014-08-09 21:03 ` Alan Mackenzie
1 sibling, 1 reply; 4+ messages in thread
From: Alan Mackenzie @ 2013-10-23 21:00 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: Emacs development discussions
Hello again, Dmitry.
On Mon, Oct 14, 2013 at 08:57:53PM +0400, Dmitry Antipov wrote:
> An issue from:
> https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00483.html
> is exactly reproduced on this header from LLVM project, most probably
> due to huge
> #ifdef __cplusplus <===============================
> extern "C" {
> #endif
> /* a lot of things */
> #ifdef __cplusplus
> } // extern "C"
> #endif
> block - a lot of things between top-level { and } hangs everything,
> without a chance to quit with C-g.
This isn't quite the cause. What is actually happening is that CC Mode
is repeatedly searching backwards from the first "#ifdef" line for almost
any punctuation character which isn't in "syntactic whitespace" (i.e. in
a comment or macro). Those 845 #defines take a lot of searching over.
This is a tricky one to fix, since I don't quite understand why the
critical bit of code is there. It was inserted into the source in 2006,
but isn't itself buggy. It is `c-at-toplevel-p' which is buggy.
But in the meantime, the following temporary patch should get your C Mode
scrolling again:
*** cc-fonts.el 2013-10-20 14:21:58.000000000 +0000
--- cc-fonts.el.temp 2013-10-23 20:36:31.000000000 +0000
***************
*** 1116,1126 ****
"[;,]\\|\\s)\\|\\'\\|\\(=\\|\\s(\\)" limit t t))
(setq next-pos (match-beginning 0)
! id-face (if (and (eq (char-after next-pos) ?\()
! (let (c-last-identifier-range)
! (save-excursion
! (goto-char next-pos)
! (c-at-toplevel-p))))
'font-lock-function-name-face
'font-lock-variable-name-face)
got-init (and (match-beginning 1)
--- 1116,1122 ----
"[;,]\\|\\s)\\|\\'\\|\\(=\\|\\s(\\)" limit t t))
(setq next-pos (match-beginning 0)
! id-face (if (eq (char-after next-pos) ?\()
'font-lock-function-name-face
'font-lock-variable-name-face)
got-init (and (match-beginning 1)
Thanks for the bug report.
> Dmitry
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Huge {...} blocks in C/C++ again
2013-10-23 21:00 ` Alan Mackenzie
@ 2014-08-09 21:03 ` Alan Mackenzie
0 siblings, 0 replies; 4+ messages in thread
From: Alan Mackenzie @ 2014-08-09 21:03 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: Emacs development discussions
Hello, Dmitry.
I've installed this patch in the trunk, revision #117676.
On Wed, Oct 23, 2013 at 09:00:09PM +0000, Alan Mackenzie wrote:
> On Mon, Oct 14, 2013 at 08:57:53PM +0400, Dmitry Antipov wrote:
> > An issue from:
> > https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00483.html
> > is exactly reproduced on this header from LLVM project, most probably
> > due to huge
> > #ifdef __cplusplus <===============================
> > extern "C" {
> > #endif
> > /* a lot of things */
> > #ifdef __cplusplus
> > } // extern "C"
> > #endif
> > block - a lot of things between top-level { and } hangs everything,
> > without a chance to quit with C-g.
> This isn't quite the cause. What is actually happening is that CC Mode
> is repeatedly searching backwards from the first "#ifdef" line for almost
> any punctuation character which isn't in "syntactic whitespace" (i.e. in
> a comment or macro). Those 845 #defines take a lot of searching over.
> This is a tricky one to fix, since I don't quite understand why the
> critical bit of code is there. It was inserted into the source in 2006,
> but isn't itself buggy. It is `c-at-toplevel-p' which is buggy.
> But in the meantime, the following temporary patch should get your C Mode
> scrolling again:
> *** cc-fonts.el 2013-10-20 14:21:58.000000000 +0000
> --- cc-fonts.el.temp 2013-10-23 20:36:31.000000000 +0000
> ***************
> *** 1116,1126 ****
> "[;,]\\|\\s)\\|\\'\\|\\(=\\|\\s(\\)" limit t t))
>
> (setq next-pos (match-beginning 0)
> ! id-face (if (and (eq (char-after next-pos) ?\()
> ! (let (c-last-identifier-range)
> ! (save-excursion
> ! (goto-char next-pos)
> ! (c-at-toplevel-p))))
> 'font-lock-function-name-face
> 'font-lock-variable-name-face)
> got-init (and (match-beginning 1)
> --- 1116,1122 ----
> "[;,]\\|\\s)\\|\\'\\|\\(=\\|\\s(\\)" limit t t))
>
> (setq next-pos (match-beginning 0)
> ! id-face (if (eq (char-after next-pos) ?\()
> 'font-lock-function-name-face
> 'font-lock-variable-name-face)
> got-init (and (match-beginning 1)
> Thanks for the bug report.
> > Dmitry
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-08-09 21:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-14 16:57 Huge {...} blocks in C/C++ again Dmitry Antipov
2013-10-18 20:18 ` Alan Mackenzie
2013-10-23 21:00 ` Alan Mackenzie
2014-08-09 21:03 ` Alan Mackenzie
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).