--- Begin Message ---
|
Subject: |
23.2; cc-mode hangs, likely during font lock |
|
Date: |
Thu, 7 Oct 2010 17:37:17 -0600 |
Emacs 23.2.1 hangs when I try to open a file containing the following C code:
cat <<EOF >test.c
int a;
void f(int x) {}
EOF
emacs test.c
Note the space preceding the first line. The content of the first
line doesn't seem to matter: so long as it starts with a space, emacs
hangs. If I remove that space, the file opens successfully. However,
if I then enter a space at the start of the first line, emacs will
hang after a second or two -- about the amount of time between font
lock updates.
By hangs I mean stops responding and takes up 100% CPU. Caught in an
infinite loop.
My stripped-down .emacs file reads as follows:
(c-add-style "my-cstyle" '(
(defun-prompt-regexp . " ")))
(defun apply-my-cstyles ()
(c-set-style "my-cstyle"))
(add-hook 'c-mode-common-hook 'apply-my-cstyles)
The problem is trivially solved by setting defun-prompt-regexp to nil.
I'm not sure why it was a space in the first place, as I never put a
space before the curly brace starting a function. But there might be
some weirdos out there who do, so I figured I'd report the bug for
their benefit.
Cheers,
Jake
In GNU Emacs 23.2.1 (x86_64-apple-darwin10.4.0, X toolkit)
of 2010-10-07 on bakers.aoc-vis.nrao.edu
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
configured using `configure '--prefix=/opt/local' '--infodir'
'/opt/local/share/info/emacs' '--without-dbus' '--without-gconf'
'--with-x-toolkit=lucid' '--without-xaw3d' '--without-carbon'
'--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png'
'CC=/usr/bin/gcc-4.2' 'CFLAGS=-pipe -O2 -arch x86_64'
'LDFLAGS=-L/opt/local/lib -arch x86_64'
'CPPFLAGS=-I/opt/local/include''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: nil
value of $XMODIFIERS: nil
locale-coding-system: nil
default enable-multibyte-characters: t
Major mode: Emacs-Lisp
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
<escape> x r e p o r t - e m <tab> <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
call-interactively: End of buffer
Quit
Saving file /Users/jhartman/.emacs...
Wrote /Users/jhartman/.emacs
Non-character input-event
Saving file /Users/jhartman/.emacs...
Wrote /Users/jhartman/.emacs
Load-path shadows:
None found.
Features:
(shadow sort mail-extr message idna ecomplete rfc822 mml easymenu
mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util
netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock
sha1 hex-util hashcash mail-utils emacsbug multi-isearch cc-styles
cc-align cc-engine cc-vars cc-defs regexp-opt tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd
fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer
select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces
cus-face files text-properties overlay md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote
make-network-process font-render-setting x-toolkit x multi-tty emacs)
--
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#7173: 23.2; cc-mode hangs, likely during font lock |
|
Date: |
Mon, 03 Oct 2011 16:43:50 -0400 |
|
User-agent: |
Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) |
Version: 24.1
I can reproduce this in 23.3, but not in the current trunk, so it
seems to have been fixed.
--- End Message ---