[simon.marshall@misys.com: RE: Font-lock assumes C++ variables instantiated via ctor are fun ctions]

* [simon.marshall@misys.com: RE: Font-lock assumes C++ variables instantiated via ctor are fun ctions]
@ 2006-11-14 12:26 Richard Stallman
  2006-11-15 16:31 ` Chong Yidong
  0 siblings, 1 reply; 2+ messages in thread
From: Richard Stallman @ 2006-11-14 12:26 UTC (permalink / raw)

Can someone please check this?

------- Start of forwarded message -------
From: "Marshall, Simon" <simon.marshall@misys.com>
To: "'emacs-pretest-bug@gnu.org'" <emacs-pretest-bug@gnu.org>
Date: Mon, 13 Nov 2006 10:46:19 -0000
MIME-Version: 1.0
Content-Type: text/plain
Subject: RE: Font-lock assumes C++ variables instantiated via ctor are fun
	ctions
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

Hi, I noticed during my weekly cvs update that cyd applied my recent patch
for "Font-lock fontifies C/C++ case keyword as a constant", thanks.

The below earlier patch for another bug hasn't been applied, was it missed?

Thanks, Simon.

- -----Original Message-----
From: Marshall, Simon 
Sent: 02 November 2006 10:48
To: 'emacs-pretest-bug@gnu.org'; 'bug-cc-mode@gnu.org'
Cc: 'Feng Li'
Subject: RE: Font-lock assumes C++ variables instantiated via ctor are
functions

Here is a patch that fixes the below problem for cvs emacs.

Feng Li sent me a patch that indicated to me where I could fix the problem
using the same solution used in previous versions of emacs.

2006-11-02  Simon Marshall  <simon@gnu.org>

	* progmodes/cc-fonts.el (c-font-lock-declarators): Use
c-at-toplevel-p
	to recognise T t() as a function declaration, rather than a variable
	instantiation, iff at the top-level or inside a class declaration.
	From an idea from Feng Li <fengli@gmail.com>.

===================================================================
RCS file: /sources/emacs/emacs/lisp/progmodes/cc-fonts.el,v
retrieving revision 1.16
diff -r1.16 cc-fonts.el
900c900,904
< 	    id-face (if (eq (char-after next-pos) ?\()
- ---
> 	    id-face (if (and (eq (char-after next-pos) ?\()
> 			     (let (c-last-identifier-range)
> 			       (save-excursion
> 				 (goto-char next-pos)
> 				 (c-at-toplevel-p))))

Simon.

> -----Original Message-----
> From: Marshall, Simon
> Sent: 06 September 2006 10:28
> To: 'bug-cc-mode@gnu.org'
> Cc: 'emacs-pretest-bug@gnu.org'
> Subject: Font-lock assumes C++ variables instantiated via ctor are 
> functions
> 
> Consider this C++ code:
> 
> class Fubar {	// Fubar as type - OK
>   Fubar();		// Fubar as function - OK
>   Fubar a;		// a as variable - OK
>   Fubar b();	// b as function - OK
>   Fubar c(A);	// c as function - OK
> };
> 
> Fubar f;		// f as variable - OK
> Fubar g();		// y as function - OK
> Fubar h(f);		// z as function - probably OK really
> 
> int fubar()
> {
>   Fubar x;		// x as variable - OK
>   Fubar y();	// y as function - OK
>   Fubar z(X);	// z as function - not OK
> }
> 
> In Emacs 21, assuming you had added "Fubar" to
> c++-font-lock-extra-types, y and z would be fontified as
> variables, on the basis that declaring functions locally (as for y) is 
> not common whereas z is almost certainly a variable and is very 
> common.  In other words, it usually does the right thing.  (Emacs 21 
> fontified y/z differently, IIRC by virtue of them being within a block 
> but not being part of a class declaration.)
> 
> In the current Emacs 22 from CVS, you don't have to add to
> c++-font-lock-extra-types, which is great.  However, y and z
> are fontified as functions.  In other words, it usually does the wrong 
> thing.
> 
> Obviously, it's very difficult to get this right without writing a C++ 
> parser.  It really isn't clear what is the best thing to do for h, 
> since it really could be either a function or a variable declaration 
> (you would have to pick apart the parameters and consult the gods).  
> But z is almost certainly going to be a variable declaration and this 
> style of variable instantiation is obviously very common.

_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

^ permalink raw reply	[flat|nested] 2+ messages in thread