Closed jgvanwyk closed 2 months ago
Fix for the PR. Let me take a look. This old issue has been sitting on the background but I never bothered to fix it…
I'm sorry for the late response to this (especially since you looked into this in #1169 a few months ago). But looking through this, I am still a little confused if we could just declare CFBundleDocumentTypes instead of using UTImportedTypeDeclarations (see https://stackoverflow.com/questions/21937978/what-are-utimportedtypedeclarations-and-utexportedtypedeclarations-used-for-on-i). Declaring CFBundleDocumentTypes allows the app to open said files already, so I'm still trying to understand exactly why we need to import the UTIs to begin with (but yes, the way MacVim is doing, aka exporting UTIs is just blatantly wrong).
Looking at existing apps, seems like VSCode just uses CFBundleDocumentTypes to declare files it could open but does not import; meanwhile Xcode does import UTIs, so I'm trying to understand the difference here to make sure we do the right thing.
The MacVim Info.plist mentions it's using the exported UTIs to declare what it could use QuickLook for so I may take a look to test if that's also the case for imported UTIs. It does seem like a weak justification IMO but wanted to get all the information first.
As an aside I'm pushing to for r180 for now, since I really want to push r179 (was hoping to get this out by EOY 2023 which obviously didn't happen) which also comes with the new Vim 9.1 release.
Also @hofman since he filed the original issues, in case he didn't see this.
I'm sorry for the late response to this (especially since you looked into this in #1169 a few months ago). But looking through this, I am still a little confused if we could just declare CFBundleDocumentTypes instead of using UTImportedTypeDeclarations (see https://stackoverflow.com/questions/21937978/what-are-utimportedtypedeclarations-and-utexportedtypedeclarations-used-for-on-i). Declaring CFBundleDocumentTypes allows the app to open said files already, so I'm still trying to understand exactly why we need to import the UTIs to begin with (but yes, the way MacVim is doing, aka exporting UTIs is just blatantly wrong).
Looking at existing apps, seems like VSCode just uses CFBundleDocumentTypes to declare files it could open but does not import; meanwhile Xcode does import UTIs, so I'm trying to understand the difference here to make sure we do the right thing.
I‘ve finally gotten around to looking at this, and now I understand how the different pieces fit together. CFBundleDocumentTypes
and UTImportedTypeDeclarations
are meant to be used in conjunction with one another. UTImportedTypeDeclarations
informs the system of file types owned by apps other than your own, and CFBundleDocumentTypes
informs the system of file types that your app can open.
A typical entry in CFBundleDocumentTypes
will include the key LSItemContentTypes
, whose value is a uniform type identifier representing the file type that your app can open (if you list an identifier here of which the system is unaware, for example if you did not import it using UTImportedTypes
, then your app won't be able to open that file type).
There are two long deprecated alternatives to LSItemContentTypes
, namely CFBundleTypeExtensions
, which is what MacVim uses currently, and CFBundleTypeOSType
, which is what VSCode uses. Both of these mechanisms were deprecated in OS X 10.5 in 2007.
Source: See the section on CFBundleDocumentTypes
in https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html
What I will do is amend my pull request to update MacVim‘s CFBundleDocumentTypes
array to use LSItemContentTypes
(I should get around to this tomorrow).
The MacVim Info.plist mentions it's using the exported UTIs to declare what it could use QuickLook for so I may take a look to test if that's also the case for imported UTIs. It does seem like a weak justification IMO but wanted to get all the information first.
MacVim should not export uniform type identifiers it does not own under any circumstances, as it breaks the user‘s file type associations.
@jgvanwyk could you explain cell value import
without continuation in PR description?
Currently MacVim exports many UTIs for filetypes it doesn't own, and its UTI definitions for many of these filetypes are incorrect. This patch aims to correct these UTI registrations and close #1169. The following lists the UTIs that were changed and how.