Re: [cdt-core-dev] Another Parser Document

[John Camelon <jcamelon@xxxxxxxxxx>]

ISourceElementRequestor is not complete as of what I put in that document. 
 

Unfortunately, extracting comments from the source falls low on the 1.2 
feature-requirement list at this time. 
I also have concerns about collecting characters into a string that most 
callbacks will not use ... until I replace the current Token 
implementatino to offsets in the file rather than copying the strings, I 
cannot see it happening in the near future without another ParserMode or 
option. 

JohnC




Mike Capp <aphelion@xxxxxxxxxxx> 
Sent by: cdt-core-dev-admin@xxxxxxxxxxx
07/14/2003 05:13 PM
Please respond to
cdt-core-dev@xxxxxxxxxxx


To
cdt-core-dev@xxxxxxxxxxx
cc

Subject
Re: [cdt-core-dev] Another Parser Document






John Camelon wrote:

>HTML format only, for those who wish to know about what I'm doing. 
>Questions, comments, criticisms and well-tempered abuse are always 
>welcome. 
>
First off, thanks for putting the doc together; even as a complete 
layman re the CDT internals I found it very clear and informative.

Only one question/suggestion: I was slightly disappointed by the absence 
of an acceptComment() on ISourceElementRequester. Especially given the 
presence of those other denizens of preprocessor country, acceptMacro() 
and enterInclusion(). One obvious application of a robust CDT parser 
interface would be a JavaDoc-style documentation generator; the ability 
to pick up doc comments is central there, and I can't see how it would 
add significant processing overhead for interface implementors which 
didn't care about comments. Hover help popups in the editor could also 
benefit from extracted doc comments.


Cheers,
Mike


P.S. Yes, I have seen the various suggestions that Eclipse use Doxygen 
for doc generation, but I'm not convinced. While I've used Doxygen a lot 
and greatly appreciate the work Dmitri has put into it, I also feel that 
its architecture is too monolithic and too reliant on an ever-increasing 
rats'-nest of config options. Also, the frankly bizarre dependency on Qt 
even for the core command-line app is always going to be a portability 
headache. I suspect that using the CDT parser for input, vanilla XML as 
intermediate representation and XSLT/XSL-FO/Batik for output (maybe 
pinching some components from Eclipse GEF for class diagram layout), 
could cover 90% of the functionality required by a JavaDoc equivalent.



_______________________________________________
cdt-core-dev mailing list
cdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-core-dev