Bug 90135 - emacs font-lock error on java file
emacs font-lock error on java file
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: emacs (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Brock Organ
:
: 90136 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-03 01:00 EDT by Need Real Name
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-15 11:06:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2003-05-03 01:00:26 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
$ cat Test1.java
 
public class Test1 {
 
  public static void main(String[] args) {
    System.getProperties().list(System.out);
  }
 
}

$ emacs -nw -q --no-site-file \
--eval '(global-font-lock-mode t)' \
--eval '(setq debug-on-error t)' Test1.java

This results in the error:
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 119 nil)
  font-lock-default-fontify-region(1 119 nil)
  font-lock-fontify-region(1 119)
  run-hook-with-args(font-lock-fontify-region 1 119)
  jit-lock-fontify-now(1 501)
  jit-lock-function(1)

This seems to happen with any java file. (the above file is just a simple
sample)  The -nw option is not necessary, I just specify it to make sure that
the problem is not due to some X font problem.  This problem resulted after an
upgrade from rh 8.0 to rh 9.

Version-Release number of selected component (if applicable):
emacs-21.2-33

How reproducible:
Always
Comment 1 Need Real Name 2003-05-03 02:08:19 EDT
*** Bug 90136 has been marked as a duplicate of this bug. ***
Comment 2 Need Real Name 2003-05-05 20:25:57 EDT
Here are a couple more test cases.

A file that is just a comment does _not_ cause an error.

$ cat NoError.java
// the simplest java file

The simplest legal file which is basically just a class definition does _not_
cause the error.

$ cat NoError.java
public class NoError {
}

The simpest useful file: a class with an embedded function definition _does_
cause the error.

$ cat AnError.java
public class AnError {
  public static void main() {
  }
}

Any hints on how to debug elisp?  The stack trace doesn't even have filenames or
line numbers.
Comment 3 Jens Petersen 2003-05-06 07:01:21 EDT
First of all, you may like to try using xemacs for java, since it comes with
the powerful jde package included.

Reproduced with emacs-21.2, but it is fixed in 21.3 AFAICT.
Could you please try with the newer emacs in rawhide and re-open
if you still a problem, thanks.

Comment 4 Need Real Name 2003-05-06 12:49:25 EDT
I upgraded the following packages from rawhide:
emacs-21.3-3.i386.rpm
emacs-el-21.3-3.i386.rpm
emacs-leim-21.3-3.i386.rpm

And I can still reproduce the problem exactly as above.

Thanks for the JDE tip.  I actually use the JDE from emacs.  I have to manually
download and install: JDE, eieio, elib, semantic, and speedbar.  It would be
great if redhat included these as rpm packages.
Comment 5 Need Real Name 2003-05-06 14:33:24 EDT
Just one other note.  The bug repros whether the JDE is loaded or not.
Comment 6 Jens Petersen 2003-05-07 16:53:37 EDT
About JDE for Emacs, please put in a separate RFE request here, thanks.

I can't see to reproduce this with 21.3 (neither with your examples
Test1.java nor AnError.java), so can you tell me exactly how to
reproduce?

Comment 7 Need Real Name 2003-05-07 19:49:15 EDT
I can repro it with the same command line shown above.

$ rpm -q emacs
emacs-21.3-3
$ rpm -V emacs
$ emacs --version
GNU Emacs 21.3.1
Copyright (C) 2002 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

$ emacs -nw -q --no-site-file --eval '(global-font-lock-mode t)' --eval '(setq
debug-on-error t)' Test1.java

The above line produces the error and stack trace as shown earlier.

Note: I'm using rh9 + emacs-21.3-3  Are you using this same setup or are you
using a complete rawhide installation?  What revision of the package are you
using?  Is there a chance that I could be missing some other upgraded package
that is fixing the problem?  The -q and --no-site-file options should limit the
behavior to just the emacs package, right?
Comment 8 Jens Petersen 2003-05-08 01:18:19 EDT
You're right, I reproduced it on a RHL9 install with emacs-21.3-3.
However with the latest rawhide, I don't get any error.  Strange.
Comment 9 Need Real Name 2003-05-08 02:52:16 EDT
More data:

downloaded ftp://ftp.gnu.org/pub/gnu/emacs/emacs-23.3.tar.gz
$ ./configure
$ make

This freshly built version does _not_ reproduce the problem on rh9.
Comment 10 Need Real Name 2003-05-08 04:06:59 EDT
Downloaded the emacs-21.3-3 source rpm (rawhide)
Compiled on rh9
This freshly built version _does_ reproduce the problem on rh9.
Comment 11 peter blicher 2003-06-03 14:29:33 EDT
I suspect this bug is related to a bug I have found in 9.0 for emacs 21.2.1.  
In my case, fontifying c++ code, the type-name font is also applied to the 
function name, for built-in types.  This did not occur with emacs 21.2.1 on 
7.3, and does not occur with the xemacs shipped with 9.0.  I observe that there 
are a large number of site lisp files that are being loaded with the version 
shipped with 9.0.  Since the version of font-lock.el is identical between 9.0 
and 7.3, some customization must be clobbering something.

In addition, and maybe this should be a separate bug, smtp mail has bugs.  
These can be traced to the smtpmail.el that is distributed in site lisp.  
Loading the gnu-distributed smtpmail.el fixes the problems.  (The problem is 
that the smtp server name is not being picked up from the correct smtpmail 
variable.  This is due to use of smtp.el in the site lisp, and a different 
smtpmail.el in site lisp.  However, I have not tracked down the precise 
location of the bug in the code.

--peter
Comment 12 peter blicher 2003-06-04 13:09:20 EDT
I yesterday reinstalled rh9 from dvd, and thereby eliminated the font lock bug 
I was  experiencing.  In the "everything" install, there are several packages 
that result in additions to emacs, such as leim, flim, and apel, as well as 
others.  I declined to install all of these for my reinstall.  Note that the 
bug I was experiencing had persisted despite my running emacs with emacs -q --
no-site-file.  I confess that I no longer remember the full emacs startup 
sequence, but I was able to verify that certain stuff gets loaded even if you 
specify -q --no-site-file.

--peter
Comment 13 Need Real Name 2003-06-05 14:13:10 EDT
Just an FYI.  I've exausted my detective skills on this bug and have resorted to
using my own, non-rpm build from the gnu sources.  I assume that since doesn't
repro in rawhide, it's not a priority and so no one at red hat is investigating
it, right?
Comment 14 Jens Petersen 2004-01-14 19:36:45 EST
Hmm, since I'm unable to reproduce the problem it is
rather hard to look further into it.

I recommend trying with a fresh install to see if you
can still reproduce it.
Comment 15 Jens Petersen 2004-04-15 11:06:28 EDT
Closing for now.  Feel free to reopen if you can still reproduce
with Fedora Core.

Note You need to log in before you can comment on or make changes to this bug.