| [cdt-dev] Augmenting CDT |
Hello,
I had some questions about augmenting or extending the CDT plugin. Specifically I'm working on a language agnostic (i.e. workings with Java, C/C++, etc). The syntax is similar to the C preprocessor directives, and our first target language is C. While all the tools work on the CLI, we are hoping to add Eclipse Support, and I am not entirely sure of the best way to do this.
Specifically our preprocessor will take some of our own preprocessor directives, swap them out for there corresponding C-isms, and then produce a valid C file, which can be compiled via gcc, etc.
We would like to get as much CDT functionality as possible without duplicating code. The extension for these augmented c files is different, say .xc. We would like it such that you can open these files up, and as much as possible they are just seamless as C files. Certain things like interacting with gdb will likely be very difficult, since the preprocessor changes line numbers, but other things should be simple, hopefully.
I've built a custom Editor, that can Partition and color our preprocessor directives directly, and also supports code folding, and (using manual Makefiles), it's fairly straight forward to build and run our augmented files. Trying to tie this in with the already existing CDT however has proved difficult, (not the least of which is that I'm not a seasoned eclipse plugin developer).
I have tried subclassing the CEditor class, and the CSourceViewerConfiguration class, and disregarding the foreboding warnings that this access is discouraged I don't seem to be able to get at the partitionor to replace it with ours, our reconcilers and damagers can color the document. I suspect that if those warnings are any indication, this is entirely the wrong approach.
Ideally going forward, we would like to have coloring, error highlight (and syntax checking), as well as the overview stuff (like the list of methods in a file, etc..) augmented with our own entities. What would be the best way to go forward with something like this, and additionally what would be the fruitful avenues of the Eclipse Plugin API to research to implement this kind of functionality. Finally what hope do we have for allowing the plugin to be as language independent as possible, (or in other words to have the maximum code re-use as possible, a simple example of difficulties here, is that the colors associated with coloring in C, come from an IColorManager, and in the JDT from a ColorManager (that is not related at all to the IcolorManager).
Thanks,
Steve Ramage