[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-core-dev] Another Parser Document
|
>
> ISourceElementRequestor is not complete as of what I put in that document.
>
It is certainly a step in the right direction appreciate the effort.
Could you however, put your document in one of the cdt-home in pdf, doc
or whatever formats.
>
> Unfortunately, extracting comments from the source falls low on the 1.2
> feature-requirement list at this time.
Mike, were you thinking also of things like doxygen ?
> 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
>
>
> _______________________________________________
> cdt-core-dev mailing list
> cdt-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-core-dev
>
--
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!
