D15532: [Astyle] Add Objective C to list of languages with formatters
René J.V. Bertin
noreply at phabricator.kde.org
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).
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...
More information about the KDevelop-devel