Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix incorrect UTI registrations #1468

Closed
wants to merge 0 commits into from
Closed

Fix incorrect UTI registrations #1468

wants to merge 0 commits into from

Conversation

jgvanwyk
Copy link

@jgvanwyk jgvanwyk commented Dec 23, 2023

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
Copy link
Member

ychin commented Dec 23, 2023

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
Copy link
Member

ychin commented Jan 3, 2024

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
Copy link
Member

ychin commented Jan 3, 2024

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

@ychin ychin added this to the Release 180 milestone Jan 3, 2024
@jgvanwyk
Copy link
Author

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
Copy link
Contributor

eirnym commented Apr 25, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

UTI registrations are wrong
3 participants