Bug 150197
| Summary: | font-lock.el and font-lock.elc behavior differs in java-mode | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Norbert Roma <norbert> |
| Component: | emacs | Assignee: | Jens Petersen <petersen> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | sundaram |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 21.4-5 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-09-05 07:45:19 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
Norbert Roma
2005-03-03 16:30:17 UTC
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)
{
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.
Note:
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): 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 emacs-common-21.3-21.FC3 Thanks. Right, I see the same md5sum. Any output for "rpm -V" on emacs, emacs-common, or emacs-el? :) micron-nr[1001]: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.] |