D15532: [Astyle] Add Objective C to list of languages with formatters

[Igor Kushnir]

igorkushnir added a comment.


  In D15532#678830 <https://phabricator.kde.org/D15532#678830>, @rjvbb wrote:
  
  > > Theoretically, Objective-C headers could be detected with //#import// magic, but that wouldn't be reliable, because Objective-C headers can start with a comment or with //#include//, which share C's syntax. So I am inclined to remove the references to //text/x-objchdr// from KDevelop.
  >
  > I'm pretty certain I have a patch that improves ObjC support in KDevelop, and also that I put it up for review at some point. Maybe it was never incorporated because of the mime info not being in the mimeinfo database, I can't remember.
  
  
  Here is your patch: D15530 <https://phabricator.kde.org/D15530>. One of your comments in that review is:
  
  > Removed the x-objchdr mimetype (to avoid additional confusion what a .h file could be) and added my current x-objc+src definition to kdevclang.xml .
  
  This comment sort of resigns to remove mentions of //x-objchdr// from KDevelop's code.
  
  >> If I understand correctly, this MIME type is currently useless in KDevelop anyway, because it is only included in MIME type lists and never appears in conditions. Is //text/x-objchdr// used in macOS? If yes, how is it distinguished from //text/x-chdr// there?
  > 
  > Again, I can't answer that question. Since Mac OS X the Mac OS chiefly uses file extensions rather than the old type and creator 4char codes that were stored in the resource fork. I rarely use the Finder for filesystem navigation but I'll try to remember to look how it labels, erm, *C* header files.
  >  KDevelop would do good to distinguish ObjC(++) from C(++) header files so it doesn't signal spurious errors when editing one, but it might be able to do that by installing a complementary mimeinfo module that isn't part of the official database.
  > 
  > ObjC headers will typically contain the `@interface` keyword, but that can of course occur quite far into the file. Idem for `@class`.
  > 
  > FWIW: once you do get KDevelop to recognise ObjC correctly, the memory footprint of the parser increases enormously as soon as it encounters such a file. I think the compilation of ObjC files also requires oodles of RAM, but that is released as soon as the compilation is done; KDevelop's parser doesn't release its memory so easily (in any case not when you simply close the file).
  
  So we don't know a reliable way to tell Objective-C headers from C headers. The dropping of //text/x-objchdr// from KCoreAddons indicates that this isn't easy as well.
  
  In D15532#678825 <https://phabricator.kde.org/D15532#678825>, @rjvbb wrote:
  
  > > 4. Will create a KDevelop merge request that removes all mentions of //text/x-objchdr//.
  >
  > I already indicated why I think that's not a good idea (but I can always just patch it back)
  
  
  As KDevelop doesn't recognize any //*.h// files as Objective-C headers on your system, I don't understand what you gain from the presence of the lines `{QStringLiteral("text/x-objchdr"), QStringLiteral("Objective-C")},` in KDevelop's code and why would you want to patch them back in. Do you think that detecting only the headers that start with `#import` as Objective-C headers would be helpful? Even if it were helpful, I don't know how to achieve that, because having two MIME types with the same magic elements (//text/x-objcsrc// and //text/x-objchdr//) wouldn't work. And neither of these two MIME types should inherit the other, right?

REPOSITORY
  R32 KDevelop

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

To: rjvbb, #kdevelop, kossebau, kfunk
Cc: igorkushnir, aaronpuchert, kfunk, kossebau, kdevelop-devel, hmitonneau, christiant, glebaccon, domson, antismap, iodelay, alexeymin, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20211012/c7afd56b/attachment-0001.htm>