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
On 15/07/2005, at 21.45, Jonathan Ragan-Kelley wrote:
[...] 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. [...]
However, somewhat more vexing was the fact that some themes [...] rely on bold text just as much as color, and I wasn't seeing it.
[...] 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.
There's a bug in ATSUI which often causes (anti aliased) bold to not show on dark backgrounds. Currently I rely on ATSUI's bold style tag, but for fonts which have a bold variant, I could probably switch font myself, and not ask for the bold style. Granted I can figure out the name, I already have approximately one page of code to try to find the proper font name, since the various sub-systems of OS X use different names for the same fonts (yes, every single part of text rendering on OS X sucks big-time!).
[...] Has anyone tried to add more sensitive language definitions with more detailed elements, like those I mentioned?
Chris tried to add a pattern for function prototypes, but there were too many false positives for me (mainly C++ initializer lists IIRC).
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
hmm... “much easier”? :)
(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)
I expect you just want to take everything that looks like a variable declaration (since type could be an externally defined class, typedef etc.)?
So stuff like: if(foo bar = fud) foo bar(42); static struct { ... } const bar[42] = { ... }; foo* const bar = &fud; etc. would mean bar is a variable?
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.
I need types of variables in current scope for the code completion, but currently there's no bridge between the code completion stuff and the parser for this. I haven't considered converting the ANTLR grammar to a TM grammar for catching the variables, it may actually work, but I'm not sure it'll be worth it ;) -- currently though my priorities are to wrap up stuff to make a 1.1 final release, so I won't touch any of this until after 1.1.
-
Allan Odgaard -
Jonathan Ragan-Kelley