Bug 148977

Summary: fatal Lisp error on fonifying .java files
Product: [Fedora] Fedora Reporter: Jake Gage <jake>
Component: emacsAssignee: Jens Petersen <petersen>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: 21.4-5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-31 01:36:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 158044    

Description Jake Gage 2005-02-17 17:43:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020

Description of problem:
I'm experiencing a bug loading Java source files with font-lock-mode
enabled.  The contents of the file don't seem to be an issue, but
longer Java source files will show only partial colorization after
load.  Here is an example file cooked up to cause the bug:

$ cat EmacsBugReportClass.java
/**
 *  This is a test class to break things.
 */
public class EmacsBugReportClass
{
}
$ emacs -nw -q --no-site-file --eval '(global-font-lock-mode t)'
--eval '(setq debug-on-error t)' EmacsBugReportClass.java

The Emacs messages buffer returns:

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 89 nil)
  font-lock-default-fontify-region(1 89 nil)
  font-lock-fontify-region(1 89)
  run-hook-with-args(font-lock-fontify-region 1 89)
  jit-lock-fontify-now(1 501)
  jit-lock-function(1)

The file comes up as being modified.  Trying to save the file (C-X
C-S), results in a prompt for a file location for saving (it doesn't
seem to know what file was loaded).

For this example file, the whole file is colorized, but for longer
Java sources only the first few lines initially colorize.


Version-Release number of selected component (if applicable):
emacs-21.3-21.FC3

How reproducible:
Always

Steps to Reproduce:
1. Create sample Java source file.
2. Load java source file.

    

Actual Results:  The Emacs messages buffer returns:

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 89 nil)
  font-lock-default-fontify-region(1 89 nil)
  font-lock-fontify-region(1 89)
  run-hook-with-args(font-lock-fontify-region 1 89)
  jit-lock-fontify-now(1 501)
  jit-lock-function(1)

The file comes up as being modified.  Trying to save the file (C-X
C-S), results in a prompt for a file location for saving (it doesn't
seem to know what file was loaded).

For this example file, the whole file is colorized, but for longer
Java sources only the first few lines initially colorize.


Expected Results:  The buffer has previously (up to and including FC2
for me) loaded Java buffers and colorized them nicely.

Additional info:  Most annoying.  Any help would be much appreciated.

Comment 1 Jens Petersen 2005-04-08 06:54:27 UTC
I'm not able to reproduce with your example.

Comment 2 Jake Gage 2005-04-08 19:18:22 UTC
(In reply to comment #1)
> I'm not able to reproduce with your example.

Interesting.  I could reproduce it on three different machines using the default
FC3 distribution with stanard updates.  What platform are you on?  Anything else
I can do to help?

I've actually (gasp) started using Eclipse since this one put a wrench in my
development.

Comment 3 Jens Petersen 2005-05-19 21:46:42 UTC
I updated cc-mode in emacs-21.4-5 to the latest version, since
that is apparently where the problem is.

Could you please test that to see if it fixes the problem for you,
and if so close this bug as fixed in rawhide.  Thanks.

[Alternatively if you're not able to test the latest emacs from
FC development or rebuild the srpm, you make like to try to install the latest
cc-mode release yourself separately and test that.  See the tracker bug 158044
for the location.]

Comment 4 Jake Gage 2005-06-13 17:49:54 UTC
Sorry Jens.  I went off to France and the Bugzilla notice got buried in my
inbox.  I'll try to test this by the end of this week.

Comment 5 Jake Gage 2005-08-30 21:31:13 UTC
Sorry again for the long delay, but this is definitely fixed.  I just tested
this in FC4.  What's the proper protocol for closing this badboy?  (I don't see
a "FIXED" resolution.)