[TxMt] Theme Trouble: C, Bold

[Allan Odgaard]

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.