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

Tue Oct 12 09:53:31 BST 2021

rjvbb added a comment.

  > Could you please cancel that email and paste its contents in a Phabricator comment?

  [grrr, replying via email didn't use to suck this much AFAICR]

  On Saturday October 09 2021 17:25:14 Igor Kushnir wrote:

  > @rjvbb, could you please try to answer the following questions?

  > Is //text/x-objc++src// the canonical name used in macOS or is there some other reason to select one of these names?

  No idea to be honest, nor how I'd figure that out...

  >   I suppose //*.mm// is used almost universally and //*.M// practically never. Is that right? If so, there is no need to complicate the MIME database with 3 //case-sensitive// attributes.

  I can indeed not remember ever having seen a .M file. That said, HFS and APFS are case insensitive but case preserving, so software can and does use filename case. I think that you should take it up with the mimeinfo maintainers what they prefer here.

  > 3. Currently //text/x-objcsrc// has only one magic pattern: "#import". My brief research indicates that many Objective-C and Objective-C++ files start with comments or //#include//. Is that right?

  They certainly can (just like C and C++ can use `#import`, at least as far as GCC and Clang are concerned). A more distinguishing test would be for the presence of an `@` symbol at the start of a line (`@class`, @interface, `@implementation`, `@end` etc), but those don't have to be present in a file either for it to be valid ObjC.
  I would add `#import` though; Apple code will typically use that.

  > 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.

  > 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).

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/25e22482/attachment.htm>