Community
Participate
Working Groups
hi, I'm looking into https://bugs.eclipse.org/bugs/show_bug.cgi?id=178386 This asks that we add provision for documentation-comment behaviours to the CDT editor, in the same way that javadoc is currently supported in JDT. For C/C++ projects we are at the disadvantage that there is no documentation-comment definition built into the language specs. Which particular third-party tool is being used to extract documentation-comments (and the way that the tool specifies documentation-comments should be distinguished from plain comments) is not a function of the file name, extension, or content type. The only way we can determine is if the user tells us "this project uses doxygen comments" or "this project uses cppdoc comments". With this in mind, it would be really neat if our IDocumentSetupParticipant was passed information about the resource being opened. We'll likely default to either no-documentation-comments or a user-specified default for when this information is unavailable (e.g. for external files). I'd like to propose an IDocumentSetupParticipantExtension which IDocumentSetupParticipant's could additionally implement to recieve the extra information (e.g. an IPath, LocationKind pair) and hope to provide a patch. is this something that could make it into the 3.4 stream in principle? thanks, Andrew
Fair request but no time to work on this. Good quality patch would be accepted. Keep in mind that file buffers and its documents can be created in non-UI threads.
Created attachment 84301 [details] proposed patch thanks! The attached patch adds support for an extension interface org.eclipse.core.filebuffers.IDocumentSetupParticipantExtension which document-setup-participants can additionally implement to receive the additional information (or null should it be unavailable). The patch also includes unit tests, and I've been using succesfully it as part of development work on 178386.
Will take a look during M5.
just to check if this will make M5? I'm just about ready to go on the CDT side so would like a chance to respond in case the patch above needs re-work.
Will look at it this week.
Hi Andrew, thanks for the patch. General direction looks good (especially having tests with it). A few comments: - don't introduce DocumentSetupParticipantHint, use setup(IDocument document,IPath location, LocationKind locationKind) - describe more explicit that implementors of the extension will not be called on the original setup callback. - update IDocumentSetupParticipant with a link to the new extension, (see IDocument and IDocumentExtension for the pattern how we document an extension) - never make tests your friend ;-) - make sure copyright date to 2008 Looking forward to new version of the patch.
Created attachment 87647 [details] reworked patch thanks for the review - I've made these changes in the above patch :)
Created attachment 87659 [details] catches up with HEAD
Comment on attachment 87659 [details] catches up with HEAD sorry - attached to the incorrect bugzilla
Committed the patch to HEAD with some minor modifications: - changed API to not allow 'null' as argument - formatting Thanks again Andrew! Available in builds > N20080125-0010.
thanks very much :)
