[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
address@hidden: RE: Font-lock assumes C++ variables instantiated via cto
From: |
Richard Stallman |
Subject: |
address@hidden: RE: Font-lock assumes C++ variables instantiated via ctor are fun ctions] |
Date: |
Tue, 14 Nov 2006 07:26:10 -0500 |
Can someone please check this?
------- Start of forwarded message -------
From: "Marshall, Simon" <address@hidden>
To: "'address@hidden'" <address@hidden>
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: 'address@hidden'; 'address@hidden'
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 <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.
_______________________________________________
emacs-pretest-bug mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------
- address@hidden: RE: Font-lock assumes C++ variables instantiated via ctor are fun ctions],
Richard Stallman <=