Red Hat Bugzilla – Bug 150197
font-lock.el and font-lock.elc behavior differs in java-mode
Last modified: 2007-11-30 17:11:01 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Gecko/20050224 Firefox/1.0.1 Fedora/1.0.1-1.3.1
Description of problem:
In java-mode the varibale and function name highlighting does not work
when the font-lock.elc library is used. Installing emacs-el and using
font-lock.el from that package turns the syntax highlighting on for
the varaible and function names.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2.load a java file
3.make sure that font-lock-mode is on
Actual Results: Function and variable names stay in default
foreground color (black).
Expected Results: Function and variable names should change color to
whatever their font-face definitions are.
The behavior is the same whether or not I have
font-lock-maximum-decoration set to t (or 3 for that matter) or not.
In fact, it's reproducible with emacs -q.
Can you please describe the exact steps you take to turn on font-lock, etc?
Works for me...
See also bug 148977.
1. Start emacs with '-q', so nothing loads from .emacs file.
2. Open a buffer with the following content:
public class Foo
public static void main(String args)
Now say M-x font-lock-mode
This results in some sytax highliting (the key words and the class name, the
type names, the strings), but the methods name (main), and the argument variable
name (args) remain black.
Now. I went and got the font-lock.el file from the emacs-common source rpm, and
repeated the procedure above with one additional step:
After starting 'emacs -q', I say
and let it load font-lock.el that I had extracted from the source rpm.
This time, desplaying the class above in the buffer and turning the font lock on
(with M-x font-lock-mode) results in the method name (main) turning blue, and
its argument (args) changing color as well.
I don't touch and decoration level controls in either scenario.
This testing procedure works equally well with X11 and the terminal (by adding
'-nw' when starting emacs from the prompt in gnome-terminal).
The source file is very short and I get no lisp errors, so I don't think it's
related to bug 148977.
I hope this helps. I think that all that's needed is compiling the current
font-lock.el in the source rpm and using that in the binary rpm instead of what
must have been a stale *.elc file that somehow got stuck in there. Thanks.
Thanks for providing more details.
(Btw you can find font-lock.el in the emacs-el subpkg.)
Hmmm, strange I see the same highlighting (incl "main" and "args") with either
font-lock.elc or font-lock.el loaded. You can reproduce this even with
"emacs -q --no-site-file" ?
Yes, the behavior is reproducible with --no-site-file.
Just for grins, here is md5sum output on my font-lock.elc. It should be what
lives in the current emacs-common rpm, since I didn't touch the original
configuraion (modulo official Fedora updates):
For completeness, here is what rpm says:
micron-nr:rpm -q -f /usr/share/emacs/21.3/lisp/font-lock.elc
Right, I see the same md5sum.
Any output for "rpm -V" on emacs, emacs-common, or emacs-el? :)
micron-nr:rpm -V emacs emacs-common emacs-el
package emacs-el is not installed
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.]