I haven't futzed with the new themes too much until recently -- I just found some decent colors and ran.
However, as I get back to C from a bunch of Python and other work, I noticed that the new themes generally seem to lack much definition of anything in C/C++. It turns out the issue is twofold:
First, of course, the classic problem of distinguishing many different kinds of elements in a simple C/C++ parser. C parsers aren't easy or fun to write, and so the current language definitions, perhaps not surprisingly, don't seem to detect declaration.function, variable, entity.class, declaration.name.class, etc.
However, somewhat more vexing was the fact that some themes (Pastels on Dark) seemed to have substantially less styling than others in C. Looking further into the theme definitions, however, revealed that Pastels on Dark, in particular, was designed to rely on bold text just as much as color, and I wasn't seeing it.
Switching fonts to Courier [New] revealed the bold face elements, but it seems odd that my font of choice -- Bitstream Vera Sans Mono, which has a perfectly good Bold which shows up in the font selection dialog, and which renders fine as the whole-document default font if set to bold -- didn't show up as bold in the elements styled to be bold-face.
I've never done any development against Apple's Font APIs, but I'd guess there's some bug which is preventing the Bold variant from being detected in the Bitstream font. Perhaps it has something to do with the fact that the default appears as BitstreamVeraSansMono–Roman (meaning that it appears that the default is set to a specific variant, rather than to the base font, since Roman stands in for Regular in the Bitstream Vera font packages)?
I'd love to see this fixed. And is there any news on the C/C++ language definition front? Has anyone tried to add more sensitive language definitions with more detailed elements, like those I mentioned? It seems this sort of task would be made much easier by the ability to define and use a symbol table from within the language definition grammars (since tokens in C-like languages generally can't be re-used, just detecting the type of their declaration should be enough to style every subsequent element with the same name in a given file), but perhaps this is too much to ask of the already freshly-rewritten language parser engine. I'd be glad to work on it, one way or another, as long as no one else is already doing so. -jrk