[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Thanks, Jeff,
I'm still early in figuring this out. Unfortunately I don't know Fortran
so I'll have to leave where we go there to the experts such as yourself
and Craig R.
What I want to see is whether our DOM is extensible enough to handle
additional, not so C-like, languages. We already have extensions for ANSI
C and C++ and then into GNU C and C++. I know Ada enough to give it a try
and see. The follow on step would be ICElement and friends which I would
create from the results of a DOM quick parse. Finally, we would have the
index which would be populated by gnatxref which is a ctags kind of thing
that also has cross reference info and should be enough to satisfy our
search engine.
The dream is that, if you can extend the DOM and ICElement and index for
your particular language, then you would get the content assist and
navigation features for free, or as free as the gdb integration seems to
be ;). I'm a long way from seeing whether the dream comes true, though.
Cheers,
Doug
cdt-dev-bounces@xxxxxxxxxxx wrote on 04/21/2005 10:26:06 PM:
> > 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
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
