Fix incorrect UTI registrations

[jgvanwyk]

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.

Before	After
export org.vim.vim-script	export org.vim.vim-script
export org.vim.tex-file	import org.tug.{tex,sty,cls}
export public.plain-text	import public.plain-text
export public.c-header	import public.c-header
export org.vim.pch-file	import public.precompiled-c-header
export public.c-plus-plus-header	import public.c-plus-plus-header
export org.vim.pch++-file	import public.precompiled-c-plus-plus-header
export public.c-source	import public.c-source
export public.objective-c-source	import public.objective-c-source
export public.objective-c-plus-plus-source	import public.objective-c-plus-plus-source
export public.c-plus-plus-source	import public.c-plus-plus-source
export public.assembly-source	import public.assembly-source
export com.apple.rez-source	import com.apple.rez-source
export com.sun.java-source	import com.sun.java-source
export com.apple.xcode.lex-source	import public.lex-source
export com.apple.xcode.yacc-source	import public.yacc-source
export public.mig-source	import public.mig-source
export com.apple.symbol-export	import com.apple.symbol-export
export com.apple.xcode.fortran-source	import public.fortran{,-77,-90,-95}-source
export com.apple.xcode.pascal-source	import public.pascal-source
export public.html	import public.html
export public.xml	import public.xml
export com.netscape.javascript-source	import com.netscape.javascript-source
export public.python-script	import public.python-script
export public.perl-script	import public.perl-script
export public.php-script	import public.php-script
export public.ruby-script	import public.ruby-script
export public.shell-script	import public.{shell,bash,zsh,csh,ksh,tcsh}-script
export com.sun.java-class	import com.sun.java-class
export org.vim.patch-file	import public.patch-file
export com.apple.xcode.strings-text	import com.apple.xcode.strings-text
export com.apple.applescript.text	import com.apple.applescript.text
export org.vim.as-file	import com.adobe.actionscript
export org.vim.asp-file	import com.microsoft.asp
export org.vim.aspx-file	import com.microsoft.aspx
export org.vim.bib-file	import org.tug.tex.bibtex
export org.vim.cs-file	import com.microsoft.c-sharp
export org.vim.cfdg-file	import org.contextfreeart.contextfree
export org.vim.csv-file	import public.comma-seperated-values-text
export org.vim.tsv-file	import public.tab-seperated-values-text
export org.vim.cgi-file	import org.vim.cgi-script
export org.vim.cfg-file	import org.vim.config-file
export org.vim.css-file	import org.w3.css
export org.vim.dtd-file	import org.w3.xml-dtd
export org.vim.dylan-file	import public.dylan-source
export org.vim.erl-file	org.erlang.erlang
export org.vim.fscript-file	org.fscript.fscript
export org.vim.hs-file	import org.haskell.haskell
export org.vim.inc-file	import org.vim.include-file
export org.vim.ics-file	import com.apple.ical.ics
export org.vim.ini-file	import com.microsoft.ini
export org.vim.io-file	import org.iolanguage.io
export org.vim.bsh-file	import org.beanshell.beanshell
export org.vim.properties-file	import com.sun.java-properties
export org.vim.jsp-file	import com.sun.java-server-pages
export org.vim.lisp-file	import org.vim.lisp-source
export org.vim.log-file	import com.apple.log
export org.vim.wiki-file	import org.mediawiki.wiki-source
export org.vim.ps-file	import com.adobe.postscript
export org.vim.scm-file	import org.vim.scheme-source
export org.vim.sql-file	import org.iso.sql
export org.vim.tcl-file	import tk.tcl.tcl
export org.vim.xsl-file	import org.w3.xsl
export public.vcard	import public.vcard
export org.vim.vb-file	import com.microsoft.visual-basic
export org.vim.yaml-file	import org.yaml.yaml
export org.vim.gtd-file	import org.vim.gtd
export net.darlingfireball.markdown	import net.darlingfireball.markdown
export org.vim.rst-file	import org.python.restructuredtext
export org.vim.vba-file	export org.vim.vimball-archive
export org.vim.vhdl-file	remove
export org.lua.lua-source	import org.lua.lua
export org.vim.v-file	import org.ieee.vhdl
export org.vim.vh-file	import org.ieee.vhdl-header

[ychin]

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…

[ychin]

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.

[ychin]

Also @hofman since he filed the original issues, in case he didn't see this.

[jgvanwyk]

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.

[eirnym]

@jgvanwyk could you explain cell value import without continuation in PR description?