Bug 76155 - font-lock-variable-name-face improperly parsed for c++ mode
Summary: font-lock-variable-name-face improperly parsed for c++ mode
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: emacs   
(Show other bugs)
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Jay Turner
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-10-17 17:03 UTC by Need Real Name
Modified: 2015-01-08 00:01 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-15 16:59:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Need Real Name 2002-10-17 17:03:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020809

Description of problem:
In c++ mode only, variables immediately following the type are not colored as
specified according to the defined color in font-lock-variable-name-face.  

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.  Remove (or move) .emacs to make sure you have no interfering options.
2.  start a source file in c-mode (ala main.c)
3.  type "int var";
4.  notice the color for int is green, the color for var is yellow.
5.  type M-x (alt-x) and c++-mode.  Watch the color for var is now green.
6.  change "int var;" to "int var,var2;" notice that var2 is the correct color.	

Actual Results:  (comments on results were are in steps)

Expected Results:  expect to have correct color for variables following types.

Additional info:

Comment 1 Need Real Name 2002-10-17 17:10:05 UTC
I forgot to include that this was the standard emacs that comes with RH 8.0:
  emacs-21.2-18

(This problem doesn't exist with the emacs in RH 7.3: emacs-21.2-2




Comment 2 Need Real Name 2002-10-17 17:13:07 UTC
Sorry for the spam -- the reproduce steps need to squeeze one more thing -- 

2a. enable global-font-lock-mode (M-x global-font-lock-mode)



Comment 3 Jens Petersen 2002-10-27 16:01:30 UTC
I'm afraid I can't reproduce this.  The colour of "var" in step 5
doesn't seem to change for me, it remains yellow-brown.

Could you explain more carefully how to reproduce this, starting
with "emacs -q"?  Thanks.

Comment 4 Need Real Name 2002-10-28 22:04:28 UTC
Restatement of procedure:  (Note that this is a stock RH 8.0 system with
everything installed and all updates.

1.  open terminal (I use Xterm, gnome-terminal worked too)
2.  start emacs with the command "emacs -q" (so that .emacs is not read in)
3.  enable global-font-lock-mode (M-x global-font-lock-mode)
3.  open a file such that the mode is c-mode, (i.e. C-x C-f main.c)
      -- you should notice here that in the status bar it is in C mode
4.  type "int var"
      -- notice that  "int" is green, and "var" is yellow-brown
5.  enable c++-mode (M-x c++-mode)
      -- notice that "var" immediately changes to the same color as int, green
6.  add to the end of the line ", var2"
      -- notice that "var2" is yellow-brown and "var" is still green


Finally, realize this is just a test case, that proves a point. For me, c++-mode
makes this mistake throughout all my c++ files.  i.e. All the first identifiers
are the same color as the type color is defined to be.  Doing this same
procedure in RH 7.3 yields proper results.  (I have two identical computers
side-by-side)  Also, opening an existing file in 7.3 versus 8.0 shows the same
phenomenon.  (8.0 has problems, 7.3 doesn't)

Comment 5 Jens Petersen 2002-10-30 05:27:29 UTC
I followed your steps through again and still can't reproduce this, neither
in a en_US.UTF-8 or ja_JP.eucJP locales for example.  I suspect there must
be some difference between our environments.
I'll try on clean 8.0 install soon.

Comment 6 Need Real Name 2002-10-30 05:48:12 UTC
While my environment is not clean as I have carried it forward since RH 4.0
days, I have tried this procedure on 5 RH 8.0 machines and as root on those
machines (in an effort to eliminate the environment as a problem)  It has
"worked" everytime.

Comment 7 Need Real Name 2002-12-11 04:39:48 UTC
Is this still not reproducible?  I have heard nothing in one month, and still
have problems.

Comment 8 Jens Petersen 2002-12-20 07:00:54 UTC
Nope, I still can't reproduce this with the latest emacs either.

Does "rpm -V emacs emacs-el" tell you anything?
It would be best if you could reproduce this on a clean install.

Comment 9 Jens Petersen 2003-01-15 16:59:08 UTC
Closing this for now,


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