Review Request: Add buddy document functionality to cpp plugin

[Martin Heide]

> On March 24, 2011, 10:35 p.m., Dmitry Risenberg wrote:
> > languages/cpp/cpplanguagesupport.cpp, lines 510-524
> > <http://git.reviewboard.kde.org/r/100796/diff/3/?file=11562#file11562line510>
> >
> >     I think it would be better to look at mimetypes, not file extensions, because 
> >     1) Your code recognizes *.cs as a buddy.
> >     2) There can be weird extensions, such as .inl, .tcc and so on.
> 
> Martin Heide wrote:
>     OK, might be better. But in this case I cannot use the mimetype list from the .desktop-file, because there is only the line:
>     X-KDevelop-SupportedMimeTypes=text/x-chdr,text/x-c++hdr,text/x-csrc,text/x-c++src
>     ...so no separate lists for headers and sources. So I would need again to hard-code the mimetypes (which Milian discouraged), like
>     QString headerMimeTypes[] = {"text/x-chdr","text/x-c++hdr"};
>     QString sourceMimeTypes[] = {"text/x-csrc","text/x-c++src"};
>     
>     So if I get you right, you suggest this: To if path1/file1.ex1 and path2/file2.ex2 are related, I have to verify via QFileInfo that path1/file1 == path2/file2, and that one of the mimetypes specifies a c(++)header and the other one a c(++)source?
> 
> Dmitry Risenberg wrote:
>     You will have to hard-code some criterion if you want to distinguish between header and source files, either mimetypes or their extensions. Currently it is the first letter, which I don't like, because it may give wrong results. So either keep a set of mimetypes or a set of extensions. Or you can split mimetypes into headers and sources by occurrence of "hdr" string in them.
> 
> Martin Heide wrote:
>     OK so Milian merged this feature already into master.
>     Do you still want me to implement these changes concerning the mimetype handling?
> 
> Milian Wolff wrote:
>     no, I convinced Dmitry that it's not neccessary. The thing is: The buddy finder code will only be called for the c/c++ mimetypes anyways, hence e.g. ".cs" will not be matches as a buddy. And ".inl" ".tcc" are - if they have a c/c++ mimetype - not paired, hence just fall through and will be handled as-is. 
>     
>     tl;dr: nothing to do, thanks for your work :)

you're welcome :) Our student project at Toulouse was very interesting, I was pleased to work for KDevelop!

OK - but wouldn't it be nice to handle .tcc and .inl files as well, because normally if a file with one of these extensions exists, there will also be a file .h with the same name, I think?


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100796/#review2157
-----------------------------------------------------------


On March 25, 2011, 2:23 p.m., Yannick Motta wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100796/
> -----------------------------------------------------------
> 
> (Updated March 25, 2011, 2:23 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Summary
> -------
> 
> Add buddy document functionality to cpp plugin.
> Related to "Add smart clean up and buddy document architecture" review request (https://git.reviewboard.kde.org/r/100874/ )
> Cpp plugin implements IBuddyDocumentFinder. foo.h an foo.cpp are buddies and the header will be placed on the left of the cpp.
> 
> 
> Diffs
> -----
> 
>   languages/cpp/cpplanguagesupport.h a1736d6 
>   languages/cpp/cpplanguagesupport.cpp 7f28518 
> 
> Diff: http://git.reviewboard.kde.org/r/100796/diff
> 
> 
> Testing
> -------
> 
> See other review.
> 
> 
> Thanks,
> 
> Yannick
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110401/47fbdcf7/attachment.html>