[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
I found the scanner stuff for partitions and coloring pretty
bizarre.
That's hard to argue with. :-)
My (not so) hidden agenda is to understand whether we have
the right DOM and indexing architecture to support a new language
If you're referring to your lightweight hierarchy -- ICElement, is it?
(I don't have the code on this machine) -- we can probably help you out
with that one. We are still in the process of building a (giant
monstrosity which is our) Fortran AST, but as soon as that's integrated,
we want to either subclass our higher-level nodes appropriately to work
in the CDT's hierarchy OR build a similar/compatible hierarchy. You
know, to get a free Outline view and what not. Any recommendations on
that are appreciated, since we haven't looked at it very seriously yet.
If our entire AST needs to comply with some CDT interfaces, um... I
haven't counted, but this thing is on the order of 400-500
classes/interfaces, and I don't have all that much interest in changing
every one of them. :-) But you might convince us anyway...
My understanding is that the indexer won't work for us in its 2.1 state,
but that's not a concern, at least right now.
The reason I made my previous post is that, supposing we get some
undergrads on the project, a lot of the not-too-difficult contributions
that users will notice are in the editor (content assist, intelligent
auto-tabbing, etc.). Parser-based syntax highlighting is still on the
list of possibilities, thanks to our no-reserved-words language. In any
case, I can see us ending up with a custom editor eventually.
So I guess I should change my question... if this happened, could we
still "get the high value features for minimal cost," as you said?
(Sounds more complicated now...)
I have to agree, though... in general, the C editor with different
syntax highlighting is completely adequate... that's exactly what we
have right now, and no one's complaining.
Jeff
