D15530: kdev-clang : somewhat more complete ObjC(++) support

Friedrich W. H. Kossebau noreply at phabricator.kde.org
Tue Sep 25 20:57:02 BST 2018


kossebau added a comment.


  In D15530#330911 <https://phabricator.kde.org/D15530#330911>, @rjvbb wrote:
  
  > >   Sure, I am mainly interested here that we use MIME type ids which also accepted elsewhere, and not invent our own here and ignore the rest of the world :)
  > >   Once e.g. shared-mime-info has some version accepted, we can then provide fall-back variants in the kdevelop s-m-i files installed.
  >
  > I don't understand, that sounds like a contradiction. As soon as s-m-i has some version accepted we could stop providing our own code (when that version has become common in distroland), is that what you wanted to say?
  
  
  Yes. I meant, once we have something outside of kdevelop accepted=recognized as MIME type id, we then know what to use ourselves as well.
  So let's first please do some effort to have a MIME type id agreed on by others (ideally this would be something done in the Objective-C++ community where you might have your contacts to poke), then we can rely on the result here (in our intermediate s-m-i data installed).
  
  > And what could be different in "their" official version - isn't an s-m-i entry just a slightly glorified extension mapping?
  
  The main feature of s-m-i is to have some database with MIME type definitions everyone uses, so things are compatible, especially when it comes to the MIME type name/id.
  And yes, it would be great to have more magic inside the database, but if no-one works on that, it's often only extension mapping.
  Still s-m-i is better than nothing and better than lots of incompatible-id bubbles.
  
  >>   At least with s-m-i the header files are "recognized" using the file suffix, which of course makes C++ headers using ".h" being mis-identified
  > 
  > I've always wondered about that, but somehow it doesn't seem to be an issue in KDevelop.
  
  At least the source-formatter is failing on C++ headers named .h and treating them as C, as it relies on info from QMime* which uses only shared-mime-info db (where there is no proper magic around to tell if it's not rather C++).

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D15530

To: rjvbb, #kdevelop
Cc: aaronpuchert, kossebau, kdevelop-devel, glebaccon, antismap, iodelay, vbspam, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20180925/c069673c/attachment.html>


More information about the KDevelop-devel mailing list