[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: RE: Font-lock assumes C++ variables instantiated via
From: |
Chong Yidong |
Subject: |
Re: address@hidden: RE: Font-lock assumes C++ variables instantiated via ctor are fun ctions] |
Date: |
Wed, 15 Nov 2006 11:31:39 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.90 (gnu/linux) |
Richard Stallman <address@hidden> writes:
> Can someone please check this?
Checked in.
> From: "Marshall, Simon" <address@hidden>
> Subject: RE: Font-lock assumes C++ variables instantiated via ctor are fun
> ctions
> To: "'address@hidden'" <address@hidden>
>
> 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
> ----------
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-devel