Semantic history: public.mpeg-2-transport-stream incorrectly opens in Atom (the text editor)

iTerm2 Build 2.9.20150523-nightly on OS X 10.10.3 stable. But the issue dates back to far earlier — a time that I can't remember. It just happens that I got bitten several times today, so I'm only reporting it now.

I'm trying to open a public.mpeg-2-transport-stream video file (with .ts extension, but that doesn't seem to matter) with ⌘+click (my Settings->Profiles->Advanced->Semantic History is set to "Open with default app"). However, the file always opens in Atom.app (the text editor), which is not even in the list of handlers, let alone the default. Here's the UTI and extension association:

> mdls -name kMDItemContentTypeTree video.ts
kMDItemContentTypeTree = (
    "public.mpeg-2-transport-stream",
    "public.movie",
    "public.audiovisual-content",
    "public.data",
    "public.item",
    "public.content"
)
> duti -l public.mpeg-2-transport-stream
com.apple.automator.mpv-launcher
com.apple.local-library
> duti -x ts
mpv-launcher.app
/Users/zmwang/dev/src/cocoa/mpv-launcher/mpv-launcher.app
com.apple.automator.mpv-launcher

Here com.apple.automator.mpv-launcher is an Automator app. It doesn't matter which app is default though, since even if I change the associate to io.mpv, or even the stock com.apple.QuickTimePlayerX, the result would be the same: the file opens in Atom. (You may see that in action in the screencast linked below.) As a side note, MP4, Matroska, etc. opens correctly with the default app (i.e., com.apple.automator.mpv-launcher), so this issue only applies to certain video codecs/containers/extensions (haven't tested extensively).

Moreover, Atom isn't my default text editor either. In fact, I seldom use Atom (I mostly use Emacs in a tty), and my default handler for public.text and public.plain-text is TextEdit:

> duti -d public.plain-text
com.apple.TextEdit
> duti -d public.text
com.apple.TextEdit

I found #3092 (closed) ("Command clicking on .patch file opens wrong editor") that seems to be related, and it says:

If we detect that a file is a text file then we try to open an editor instead of launching the default app. In commit e4472a5d I changed it to use the default app if it is an editor, and that'll be in tomorrow's nightly build.

But I don't see how a public.movie can be mistaken as text, less why Atom is opened instead of TextEdit, in case it is indeed incorrectly treated as text.

I have switched to "Run command... open \1" for the moment and it works great, by the way.

---

Attachments:

com.googlecode.iterm2.plist

debuglog.txt.gz

---

Associated screencast:

Reassigned to @gnachman

Milestone changed to Ship 3.0

What is the output of /usr/bin/file /tmp/video.ts? The test for whether it is a text file is if this output contains the word "text". For me a .ts file gives "bbb24p_00.ts: MPEG transport stream data" and it correctly opens in Quicktime.

Indeed, I noticed that some of my MPEG-TS files are identified by file as TeX font metric data, and these are the ones that would be opended in Atom (still there's no such word as text in the output, though):

> file 20150625-magic-sample.ts
20150625-magic-sample.ts: TeX font metric data (�������������������������������)

However, libmagic 5.23 installed via Homebrew correctly identifies it as MPEG transport stream data. Maybe /usr/bin/file is using a heavily outdated version of libmagic? Here is a sample file, in case you are interested: http://1drv.ms/1HjVLpF.

By the way, any idea about why Atom.app is opened, not TextEdit.app, TextWrangler.app, Emacs.app, or whatever?

Moreover, maybe it's a better idea to determine the default app by UTI?

This might be a good time to revisit the special handling of text files. I think the default setting should do away with the baked in editors and always use your default app for that file type.

Note to self: I have a start on this in the simplifySemanticHistory branch.

I think the default setting should do away with the baked in editors and always use your default app for that file type.

Agreed. Anything else just adds confusion.

Status changed to closed

Fixed in commit 972bba7c. I hope this doesn't cause too much breakage because of changing the default behavior, but it is the right thing to do.

I forgot to push it, but it's there now.

mentioned in issue #5857 (closed)