I'm fairly sure this never made it to the lists, so here it is again... I'm not on either mailing list, so plz include me directly if you have questions.
-----Original Message----- From: Marshall, Simon Sent: 16 August 2006 18:30 To: '[EMAIL PROTECTED]' Cc: 'Emacs Pretest Bug (emacs-pretest-bug@gnu.org)' 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. I'm off on holiday, so let the flame fest begin! Simon. _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug