<table><tr><td style="">rjvbb added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D15532">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Could you please cancel that email and paste its contents in a Phabricator comment?</p></blockquote>

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

<p>On Saturday October 09 2021 17:25:14 Igor Kushnir wrote:</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p><a href="https://phabricator.kde.org/p/rjvbb/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@rjvbb</a>, could you please try to answer the following questions?</p></blockquote>



<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Is <em>text/x-objc++src</em> the canonical name used in macOS or is there some other reason to select one of these names?</p></blockquote>

<p>No idea to be honest, nor how I'd figure that out...</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">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.</pre></div></blockquote>

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

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><ol class="remarkup-list" start="3">
<li class="remarkup-list-item">Currently <em>text/x-objcsrc</em> has only one magic pattern: "#import". My brief research indicates that many Objective-C and Objective-C++ files start with comments or <em>#include</em>. Is that right?</li>
</ol></blockquote>

<p>They certainly can (just like C and C++ can use <tt style="background: #ebebeb; font-size: 13px;">#import</tt>, at least as far as GCC and Clang are concerned). A more distinguishing test would be for the presence of an <tt style="background: #ebebeb; font-size: 13px;">@</tt> symbol at the start of a line (<tt style="background: #ebebeb; font-size: 13px;">@class</tt>, <span class="phabricator-remarkup-mention-unknown">@interface</span>, <tt style="background: #ebebeb; font-size: 13px;">@implementation</tt>, <tt style="background: #ebebeb; font-size: 13px;">@end</tt> etc), but those don't have to be present in a file either for it to be valid ObjC.<br />
I would add <tt style="background: #ebebeb; font-size: 13px;">#import</tt> though; Apple code will typically use that.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Theoretically, Objective-C headers could be detected with <em>#import</em> magic, but that wouldn't be reliable, because Objective-C headers can start with a comment or with <em>#include</em>, which share C's syntax. So I am inclined to remove the references to <em>text/x-objchdr</em> from KDevelop.</p></blockquote>

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

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>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 <em>text/x-objchdr</em> used in macOS? If yes, how is it distinguished from <em>text/x-chdr</em> there?</p></blockquote>

<p>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.<br />
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.</p>

<p>ObjC headers will typically contain the <tt style="background: #ebebeb; font-size: 13px;">@interface</tt> keyword, but that can of course occur quite far into the file. Idem for <tt style="background: #ebebeb; font-size: 13px;">@class</tt>.</p>

<p>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).</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D15532">https://phabricator.kde.org/D15532</a></div></div><br /><div><strong>To: </strong>rjvbb, KDevelop, kossebau, kfunk<br /><strong>Cc: </strong>igorkushnir, aaronpuchert, kfunk, kossebau, kdevelop-devel, hmitonneau, christiant, glebaccon, domson, antismap, iodelay, alexeymin, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd<br /></div>