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: '[email protected]'; '[EMAIL PROTECTED]' 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 <[EMAIL PROTECTED]> * 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 <[EMAIL PROTECTED]>. =================================================================== 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: '[EMAIL PROTECTED]' > Cc: '[email protected]' > 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 [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
