Finder "Open With" does not offer MacVim for .json/.toml/.ts or for dotfiles (.zshrc, .env) #1704

Is your feature request about something that is currently impossible or hard to do? Please describe the problem.

Opening a .json file or a dotfile such as .zshrc in MacVim from Finder takes a detour through "Open With → Other…" every time, because MacVim is not offered in the right-click → Open With menu for them. Two groups of files are affected:

1. Modern developer formats that MacVim already has syntax support for, but which aren't registered in the bundle: .json, .toml, .ts, .tsx, .jsx, .mjs, .cjs, .astro, .svelte, .graphql, .go, .rs.
2. Dotfiles and extensionless files: .zshrc, .env, .gitignore, Dockerfile.

The relevant current state of src/MacVim/Info.plist (master):

• 76 CFBundleDocumentTypes entries, 176 distinct extensions, 27 LSItemContentTypes values.
• LSHandlerRank is set on no entry, so every existing claim is at Apple's documented default of Default.
• No entry claims json, toml, ts, tsx, jsx, mjs, cjs, astro, svelte, graphql, go, rs, vue, public.json, public.yaml, public.data, public.text or public.plain-text.
• public.plain-text, public.html, public.xml and others are exported in UTExportedTypeDeclarations. That is the separate problem reported in MacVim exports standard UTIs, and does it wrongly, messing up the system #916 and UTI registrations are wrong #1169; I am not proposing to touch the export list here. This request is only about the types MacVim claims in CFBundleDocumentTypes.

For case 2 the cause is concrete: a file with no extension, including a dotfile, is typed public.data by Launch Services, and MacVim claims no public.data document type, so there is no path by which Finder can offer it:

$ mdls -name kMDItemContentType ~/.zshrc
kMDItemContentType = "public.data"

$ mdls -name kMDItemContentTypeTree ~/.zshrc
kMDItemContentTypeTree = (
    "public.data",
    "public.item"
)

(Note it is public.data, not public.plain-text.)

Describe the solution you'd like

Two additional document type entries in src/MacVim/Info.plist, both with LSHandlerRank = Alternate:

<dict>
  <key>CFBundleTypeName</key>
  <string>All Files (dotfiles and extensionless files)</string>
  <key>CFBundleTypeRole</key>
  <string>Editor</string>
  <key>LSHandlerRank</key>
  <string>Alternate</string>
  <key>LSItemContentTypes</key>
  <array>
    <string>public.data</string>
  </array>
</dict>
<dict>
  <key>CFBundleTypeName</key>
  <string>Developer source and configuration file</string>
  <key>CFBundleTypeRole</key>
  <string>Editor</string>
  <key>LSHandlerRank</key>
  <string>Alternate</string>
  <key>LSItemContentTypes</key>
  <array>
    <string>public.json</string>
    <string>public.yaml</string>
  </array>
  <key>CFBundleTypeExtensions</key>
  <array>
    <string>toml</string>
    <string>ts</string>
    <string>tsx</string>
    <string>jsx</string>
    <string>mjs</string>
    <string>cjs</string>
    <string>astro</string>
    <string>svelte</string>
    <string>graphql</string>
    <string>gql</string>
    <string>vue</string>
    <string>go</string>
    <string>rs</string>
  </array>
</dict>

Alternate is deliberate for both, including public.data: MacVim would appear in the "Open With" menu without ever being made the default handler and without taking over icons or associations. Since public.data is the type of every file Launch Services can't classify more precisely, claiming it at Default seems more likely to surprise people than to help them; Alternate keeps the change additive. If you'd prefer Default for the developer formats specifically, that's a one-string change.

On the UTIs: public.json and public.yaml are system-declared types. public.toml and public.configuration do not exist as system UTIs, so for toml, ts, tsx and the rest I've used plain CFBundleTypeExtensions, which still works. If you'd rather stay UTI-only, the equivalent is a MacVim-owned org.vim.* type per format carrying a public.filename-extension tag spec — which is what the comment at the top of the plist already prescribes for new file types.

For reference, in other macOS editors: Zed declares public.plain-text, public.text and public.utf8-plain-text at Alternate in crates/zed/resources/info/DocumentTypes.plist; SilentText declares public.data at Alternate; HexFiend claims public.data at Owner because it has to open anything.

Describe alternatives you've considered

• Adding public.plain-text / public.text (also at Alternate) instead of public.data. That covers text-ish extensionless files but not the ones typed public.data, which is what mdls reports for dotfiles, so it wouldn't fix case 2.
• Registering each missing format as its own org.vim.* exported type. More precise and closer to the plist's existing convention, but much larger; happy to do it if you prefer that shape.
• Extending only the existing extension lists and not using UTIs at all (essentially what Zed does). public.json/public.yaml seem worth declaring properly, but I can drop them.
• Folding these additions into the open Fix incorrect UTI registrations #1489 instead of a separate PR — see below; I'd rather follow your preference than create a conflict.

Additional context

Related, not duplicates:

• MacVim exports standard UTIs, and does it wrongly, messing up the system #916 and UTI registrations are wrong #1169 -> MacVim exports standard UTIs it does not own. Real bug, different mechanism from this request (exports vs. claims); I'm not proposing to touch UTExportedTypeDeclarations.
• PR Fix incorrect UTI registrations #1489 (open since Apr 2024) rewrites the same file (+825/−761) to use LSItemContentTypes instead of CFBundleTypeExtensions. It adds public.plain-text, public.source-code, public.script and public.shell-script, but none of json, toml, ts, tsx or public.data, so this request is complementary. How would you like it sequenced: land Fix incorrect UTI registrations #1489 first and follow up, or rebase it with these entries on top? I'd rather not open a PR that conflicts with work already in flight.
• Adding filetype icons for more formats #1696 (open) asks about .ts/.tsx icons and mentions getting Finder to open those files with MacVim. If you'd rather the extension part lived there instead, that works for me.

I'm happy to submit a src/MacVim/Info.plist PR. Which scope would you prefer:

• (a) both entries above,
• (b) only the public.data (Alternate) entry,
• (c) only the developer formats,
• or (d) a rebase of Fix incorrect UTI registrations #1489 with these additions on top?

(I don't think this change can carry a test -> there's no harness for bundle metadata as far as I can tell)

Disclosure: AI assistance used to help investigate (parsing src/MacVim/Info.plist, searching for related issues and precedents) and to draft this report. I reproduced the mdls results on my own machine and reviewed everything before posting.