Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 150197 - font-lock.el and font-lock.elc behavior differs in java-mode
font-lock.el and font-lock.elc behavior differs in java-mode
Product: Fedora
Classification: Fedora
Component: emacs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Depends On:
Blocks: EmacsFontLockProblem
  Show dependency treegraph
Reported: 2005-03-03 11:30 EST by Norbert Roma
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 21.4-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-05 03:45:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Norbert Roma 2005-03-03 11:30:17 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):
emacs-common-21.3-21.FC3, emacs-el-21.3-21.FC3

How reproducible:

Steps to Reproduce:
1.Start emacs
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.

Additional info:

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.
Comment 1 Jens Petersen 2005-04-08 03:07:18 EDT
Can you please describe the exact steps you take to turn on font-lock, etc?
Works for me...

See also bug 148977.
Comment 2 Norbert Roma 2005-04-10 08:38:36 EDT
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)
	System.out.println("Hello wolrd!");

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
M-x load-file
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.
Comment 3 Jens Petersen 2005-04-10 09:43:42 EDT
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" ?
Comment 4 Norbert Roma 2005-04-10 10:11:11 EDT
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):

30523aab431f4dea11fdfc7a1426127e  /usr/share/emacs/21.3/lisp/font-lock.elc

For completeness, here is what rpm says:
micron-nr[1005]:rpm -q -f /usr/share/emacs/21.3/lisp/font-lock.elc

Comment 5 Jens Petersen 2005-04-10 10:15:38 EDT
Right, I see the same md5sum.

Any output for "rpm -V" on emacs, emacs-common, or emacs-el? :)
Comment 6 Norbert Roma 2005-04-10 10:23:35 EDT
micron-nr[1001]:rpm -V emacs emacs-common emacs-el
package emacs-el is not installed

Comment 7 Jens Petersen 2005-05-19 17:46:40 EDT
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.]

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