Re: font locking problem

[Lowell Kirsh <lkirsh@cs.ubc.ca>]

Thanks for the help. I won't post my java source here because I know 
that it's ok. All java files cause the same problems. Good to know about 
jit-lock as a replacemnet for lazy-lock. I'll be sure to give it a try.

Lowell

Alan Mackenzie wrote:
> 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("?Ã \x18Ä?Åed	#?Æ ?Ç\x12+Ã?" [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
> 
>