Re: address@hidden: RE: Font-lock assumes C++ variables instantiated via ctor are fun ctions]

[Chong Yidong]

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