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.