Bug 126165

Summary: font-lock mode fails to fontify preprocesser definitions
Product: [Fedora] Fedora Reporter: Ted Baltz <eabaltz>
Component: emacsAssignee: Jens Petersen <petersen>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-06-04 07:00:39 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 Ted Baltz 2004-06-16 23:24:01 UTC
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.

Comment 1 Jens Petersen 2004-08-05 03:01:06 UTC
> 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.

Comment 2 Ted Baltz 2004-08-05 05:55:16 UTC
> 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.

Comment 3 Jens Petersen 2004-09-29 16:49:26 UTC
How about with "emacs --no-site-file"?

Comment 4 Ted Baltz 2004-09-30 05:50:04 UTC
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.

Comment 5 Mark Huang 2005-01-25 17:22:33 UTC
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.

Comment 6 Jens Petersen 2005-02-24 13:40:02 UTC
Still don't know how to reproduce this.

You're running emacs under X windows?
What locale are you using?

Comment 7 Mark Huang 2005-02-24 20:39:12 UTC
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.

Comment 8 Ted Baltz 2005-02-24 22:02:21 UTC
I have

LANG=en_US.ISO8859-1
LC_COLLATE=C

The problem persists if I remove both definitions.

Comment 9 Jens Petersen 2005-05-19 21:46:43 UTC
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.]

Comment 10 Ted Baltz 2005-06-04 07:00:39 UTC
Yup, the new version of c-mode did the trick.  Thanks.