[TxMt] Theme Trouble: C, Bold

[Jonathan Ragan-Kelley]

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