font locking problem

font locking problem

[Lowell Kirsh]

I am having emacs problems. First, here is my entire .emacs file:

(require 'font-lock)
(require 'lazy-lock)
(global-font-lock-mode t)
(setq font-lock-support-mode 'lazy-lock-mode)

Now here's my problem: I start up (GNU) emacs and then try to visit a 
java file. The computer beeps and in the minibuffer it says:

"Wrong type argument: integer-or-marker-p, nil"

and doesn't display the file on the screen. But when I do a C-x b, it 
shows that the file has been loaded into a buffer. And there's one more 
problem - the java file buffer thinks it's been modified, even though it 
hasn't. When visiting that buffer, I try to undo but there is "no more 
undo information".

Any ideas? This seems like a bug to me, but I don't want to jump to 
conclusions too soon.

Lowell

Re: font locking problem

[Kevin Rodgers]

Lowell Kirsh wrote:

> I am having emacs problems. First, here is my entire .emacs file:
> 
> (require 'font-lock)
> (require 'lazy-lock)
> (global-font-lock-mode t)
> (setq font-lock-support-mode 'lazy-lock-mode)
> 
> Now here's my problem: I start up (GNU) emacs and then try to visit a 
> java file. The computer beeps and in the minibuffer it says:
> 
> "Wrong type argument: integer-or-marker-p, nil"
> 
> and doesn't display the file on the screen. But when I do a C-x b, it 
> shows that the file has been loaded into a buffer. And there's one more 
> problem - the java file buffer thinks it's been modified, even though it 
> hasn't. When visiting that buffer, I try to undo but there is "no more 
> undo information".
> 
> Any ideas? This seems like a bug to me, but I don't want to jump to 
> conclusions too soon.

Start emacs with the --debug-on-init option, to find out exactly where the
error occurs.

-- 
Kevin Rodgers

Re: font locking problem

[Lowell Kirsh]

It doesn't say anything of interest: just "Wrong type argument: 
integer-or-marker-p, nil"

Lowell

Kevin Rodgers wrote:
> Lowell Kirsh wrote:
> 
>> I am having emacs problems. First, here is my entire .emacs file:
>>
>> (require 'font-lock)
>> (require 'lazy-lock)
>> (global-font-lock-mode t)
>> (setq font-lock-support-mode 'lazy-lock-mode)
>>
>> Now here's my problem: I start up (GNU) emacs and then try to visit a 
>> java file. The computer beeps and in the minibuffer it says:
>>
>> "Wrong type argument: integer-or-marker-p, nil"
>>
>> and doesn't display the file on the screen. But when I do a C-x b, it 
>> shows that the file has been loaded into a buffer. And there's one 
>> more problem - the java file buffer thinks it's been modified, even 
>> though it hasn't. When visiting that buffer, I try to undo but there 
>> is "no more undo information".
>>
>> Any ideas? This seems like a bug to me, but I don't want to jump to 
>> conclusions too soon.
> 
> 
> Start emacs with the --debug-on-init option, to find out exactly where the
> error occurs.
> 

Re: font locking problem

[Alan Mackenzie]

Lowell Kirsh <lkirsh@cs.ubc.ca> wrote on Mon, 03 May 2004 19:32:26 -0700:
> I am having emacs problems. First, here is my entire .emacs file:

> (require 'font-lock)
> (require 'lazy-lock)
> (global-font-lock-mode t)
> (setq font-lock-support-mode 'lazy-lock-mode)

Would you tell us your Emacs version number (M-x emacs-version) and your
CC Mode version number (M-x c-version), please.

> Now here's my problem: I start up (GNU) emacs and then try to visit a 
> java file. The computer beeps and in the minibuffer it says:

> "Wrong type argument: integer-or-marker-p, nil"

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.

> and doesn't display the file on the screen. But when I do a C-x b, it 
> shows that the file has been loaded into a buffer. And there's one more 
> problem - the java file buffer thinks it's been modified, even though it 
> hasn't. When visiting that buffer, I try to undo but there is "no more 
> undo information".

What's happening here is that it's started the font locking, but not
finished it.  Font locking works by adding "text properties" (for example
"red text on black background") to bits of the buffer.  Changing text
properties counts as changing the buffer (unfortunately, in my view).
Each time font locking has done its bit, it rubs out the "buffer-changed"
mark.  Font locking also takes steps to prevent these text-property
changes going onto the undo list, because they're not what people
typically want to undo.  Because the font locking has crashed, it leaves
the buffer in a "changed" state.

> Any ideas? This seems like a bug to me, but I don't want to jump to 
> conclusions too soon.

Oh, it's definitely a bug.  :-)  The solution is likely to be along the
lines "please upgrade to ..... version ...., which can be downloaded from
<http://..../..../....>".

> 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").

Re: font locking problem

[Lowell Kirsh]

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

> 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)


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).

Lowell

Re: font locking problem

[Alan Mackenzie]

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

-- 
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").

Re: font locking problem

[Lowell Kirsh]

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
> 
> 

Re: font locking problem

[Stefan Monnier]

>> 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)   <====================
[...]
> 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?)

font-lock.el has some `defsubst' (i.e. functions that get inlined) so the
backtrace is "incomplete".  The call to eval is actually in
font-lock-apply-highlight or in font-lock-fontify-anchored-keywords (both
inlined functions called from font-lock-fontify-keywords-region).

If you load font-lock.el (i.e. the source code), the backtrace will be
a lot more complete.


        Stefan

Re: font locking problem

[Lowell Kirsh]

Strange... When I change my .emacs from (require 'font-lock) to (load 
"font-lock.el") my problems go away. Why would this make a difference?

Lowell

Stefan Monnier wrote:
>>>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)   <====================
> 
> [...]
> 
>>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?)
> 
> 
> font-lock.el has some `defsubst' (i.e. functions that get inlined) so the
> backtrace is "incomplete".  The call to eval is actually in
> font-lock-apply-highlight or in font-lock-fontify-anchored-keywords (both
> inlined functions called from font-lock-fontify-keywords-region).
> 
> If you load font-lock.el (i.e. the source code), the backtrace will be
> a lot more complete.
> 
> 
>         Stefan

Re: font locking problem

[Kevin Rodgers]

Lowell Kirsh wrote:
 > Strange... When I change my .emacs from (require 'font-lock) to (load
 > "font-lock.el") my problems go away. Why would this make a difference?

It could have something to do with the byte compiler or the the way
font-lock.el was compiled.  Does (load "font-lock.elc") reintroduce the
problem?

What does `M-x locate-library RET font-lock' show? And does `M-x
list-load-path-shadows' show anything suspicious?

-- 
Kevin Rodgers