[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Font-lock assumes C++ variables instantiated via ctor are fun ctions
From: |
Marshall, Simon |
Subject: |
RE: Font-lock assumes C++ variables instantiated via ctor are fun ctions |
Date: |
Thu, 2 Nov 2006 10:48:20 -0000 |
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 <address@hidden>
* 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 <address@hidden>.
===================================================================
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: 'address@hidden'
> Cc: 'address@hidden'
> 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.
- RE: Font-lock assumes C++ variables instantiated via ctor are fun ctions,
Marshall, Simon <=