From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Description of problem:
When editing C files with font-lock enabled, preprocessor definitions
are not fontified as variables. This occurs with "emacs -q" and
manually running font-lock-mode for a C file. A vanilla emacs 21.3
does not display this behavior when built for FC2 (definitions are
fontified as variables).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2.C-x C-f foo.c
3.type "#define foo bar"
4.type "float baz;"
6.observe that "foo" is not fontified, but "baz" is
Actual Results: preprocessor definition is not fontified with
Expected Results: preprocessor definition should be fontified with
RedHat 9 (emacs-21.2-33) does not have this problem.
> A vanilla emacs 21.3 does not display this behavior when built for FC2
So you saying that this works with a build of emacs-21.3.tar.gz
but not the emacs in FC2?
Following the steps you describe for me it works fine for me.
> So you saying that this works with a build of emacs-21.3.tar.gz
> but not the emacs in FC2?
That's right. The FC2 emacs fails, but building emacs-21.3.tar.gz
works fine (with the one caveat that setarch i386 is required). For
what it's worth, I have this problem with two separate FC2 installs
(P4 desktop, PIII laptop).
I did choose to install everything, including all languages, on both
machines, and they were both clean installs, and the issue was there
before I did anything else.
How about with "emacs --no-site-file"?
The problem is still there with both:
emacs -q --no-site-file
One added bit of info, my work machine was just upgraded to
"Red Hat Enterprise Linux WS release 3 (Taroon Update 3)" which has
emacs-21.3-4, and the problem is NOT there.
I see this problem on Fedora Core 3 emacs-21.3-17 as well, both with
and without "-q --no-site-file", and with and without lazy-lock
enabled (which causes problems for me in Makefiles with conditionals
emacs-21.3-4 does not have the problem.
Still don't know how to reproduce this.
You're running emacs under X windows?
What locale are you using?
As in bug 145759
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145759), I see
this problem under both X Windows and consoles, with both
LANG=en_US.UTF-8 and LC_ALL=C, and suspect that the bugs are related.
The problem persists if I remove both definitions.
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.]
Yup, the new version of c-mode did the trick. Thanks.