[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: font locking problem
From: |
Alan Mackenzie |
Subject: |
Re: font locking problem |
Date: |
Fri, 7 May 2004 08:33:56 +0000 |
User-agent: |
tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (Linux/2.0.35 (i686)) |
Lowell Kirsh <lkirsh@cs.ubc.ca> wrote on Wed, 05 May 2004 14:12:54 -0700:
> Alan Mackenzie wrote:
>> Would you tell us your Emacs version number (M-x emacs-version) and your
>> CC Mode version number (M-x c-version), please.
> emacs-version: 21.3.1
> c-version: 5.28
OK, thanks! These two certainly _ought_ to work sensibly together.
>> That's an internal coding error, probably in CC Mode. Try setting
>> `debug-on-error' (M-: (setq debug-on-error t)), then visit the file again.
>> That should give a stack dump.
> Here's a stack dump:
> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
> goto-char(nil)
> eval((goto-char (match-beginning 4))) <====================
> font-lock-fontify-keywords-region(1 1515 t) <====================
> font-lock-default-fontify-region(1 1515 t)
> font-lock-fontify-region(1 1515 t)
> byte-code("?Ã Ä?Åed #?Æ ?Ç+Ã?" [save-match-data-internal verbose
> font-lock-fontified match-data ((set-match-data
> save-match-data-internal)) font-lock-fontify-region
> font-lock-after-fontify-buffer t] 4)
> font-lock-default-fontify-buffer()
> font-lock-fontify-buffer()
> font-lock-mode()
> turn-on-font-lock()
> turn-on-font-lock-if-enabled()
> global-font-lock-mode-buffers()
> run-hooks(find-file-hooks)
> after-find-file(nil t)
> find-file-noselect-1(#<buffer FileTokenizer.java>
> "~/java/FileTokenizer.java" nil nil "~/java/FileTokenizer.java" (3385326
> 775))
> find-file-noselect("~/java/FileTokenizer.java" nil nil 1)
> find-file("~/java/FileTokenizer.java" 1)
> call-interactively(find-file)
Quick question: does this problem happen with any file.java, or is it
only FileTokenizer.java which crashes? If the latter, is there a
(java) syntactic error in this file? [Just for clarity: even if there
is such an error, Emacs shouldn't be bailing out on it ;-]
I've had a look at the code in font-lock.el, but can't make much of the
information in the dump. (In particular, I can't see the connection
between the two lines of the dump I've marked with "<=======", which is
the critical bit. Stefan, what am I missing?)
The file FileTokenizer.java is only 1515 bytes long, isn't it? Could you
possibly post it here (or even email it to me on acm@muc.de), so that I
could step through it with a debugger?
> So, what should I do? Work around this error until the next version
> comes out? I'd rather do that than build from the newest cvs source
> (laziness).
Yes, I can certainly empathise with you on that one. ;-)
One thing to do would be to try with `jit-lock-mode' in place of
`lazy-lock-mode'. jit-lock is based on the same ideas as lazy-lock. It
was a reimplementation done after it emerged that there were fundamental
problems with lazy-lock.
> Lowell
--
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").