Red Hat Bugzilla – Bug 126165
font-lock mode fails to fontify preprocesser definitions
Last modified: 2007-11-30 17:10:44 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615 Firefox/0.9 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): emacs-21.3-12 How reproducible: Always Steps to Reproduce: 1.emacs -q 2.C-x C-f foo.c 3.type "#define foo bar" 4.type "float baz;" 5.M-x font-lock-mode 6.observe that "foo" is not fontified, but "baz" is Actual Results: preprocessor definition is not fontified with font-lock-variable-name-face Expected Results: preprocessor definition should be fontified with font-lock-variable-name-face Additional info: 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 and emacs --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 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145759)). RHAS-3 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.
I have LANG=en_US.ISO8859-1 LC_COLLATE=C 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.