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.
I'm not able to reproduce with your example.
(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.
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.]
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.
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.)