Hi Jeff,
The Semantic parse could do what you are looking for, but there is
no infrastructure to handle it.
In addition, most of the parsers, such as the ones for C++, do not
parse function bodies. There are built-in functions in Emacs Lisp
that balance parenthetic expressions, such as the { } in C, so those
are used to make parsing faster.
In addition, Semantic doesn't keep a full parse tree. The parsers
only collect tag information, so that's the extent of the parse tree
that is left.
As such, to do what you want, you would have to write a parser from
scratch that parsed all of C (or whatever language you wanted) and
then build up a little infrastructure to do coloring instead of
creating tags. It's been on my todo list to try it out for a long
time, but I've been trying to get the smart completion thingy and some
code generation tools working reliably instead.
If you use Java, then you are in luck as David has written a Java
parser that will parse the whole file.
Good Luck
Eric
>>> Jeff Wheeler <jeff@...> seems to think that:
>Hey,
>
>I'm rather new to Cedet, Lisp and Emacs, coming from the world of
>Textmate. I really like what I see, but there is one thing that I think
>Semantic has very nearly done, but from what I can tell has left undone.
>
>Let me explain a bit of context, first, though.
>
>Textmate has the concept of "scopes" which allows certain features, most
>importantly the syntax highlighting and tab triggers, to know their spot
>in the parse tree. Textmate is lame and does this via regexes (although
>recursively submatching elements to form the tree, as far as I know),
>although it still is a very powerful system.
>
>The highlighting in Textmate can therefore be somewhat similar to CSS,
>in how it cascades. A "scope selector" is very similar to a CSS
>selector but for TM themes; for example, one could have a
>background-style for "source.lisp", another style for "keyword" (e.g.
>bold), and then a style for "source.lisp keyword" which, like CSS, would
>inherit the properties from both the other elements (or could simply
>change the color, and not add any conflicting rules, so all would be
>applied).
>
>Now, the CSS-like syntax is a bit complicated, and I don't see how it
>could fit into Lisp easily. However, to me, it makes a lot of sense to
>have a syntax highlighter based on the Semantic parser, rather what I
>see in Font Lock (very simple highlighting that is rather unintelligent,
>relatively).
>
>Because the parse tree already exists, I assume doing something like
>this would require simply allowing styling different elements, and not
>overriding parent styles. That way, a parent could style one property
>(e.g. make the text italics) and the child could redefine a different
>property, without changing the parent's properties (and therefore, the
>child would also be italicized).
>
>>From my understanding, nothing like this exists, and I can't find any
>discussion of anything like this on this mailing list. I'd be willing
>to play with it, if I could get a few pointers in the right direction
>(as I said, I'm brand new to a lot of these things).
>
>Jeff Wheeler
>
>(p.s., I'm sending this message again because it does not appear to
>have gone through the first time. If I've double-posted, I sincerely
>apologize.)
[ ... ]
--
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org
|