"Fetching..." Behavior in Finder "Open With" Menu in Yosemite

I don't know if other people have notice this in Yosemite:

With a file in Finder in focus, when you move the cursor to "Open With" entry, whether from context menu or menu bar -> File, a "Fetching..." subentry appears.

A moment later, the usual suspects show up, as they did in previous OS X versions.

This behavior, I assume, is supposed to be an improvement. Since /Application/***.app/Contents/Info.plist is live-fetched, an user no longer need to reset LaunchServices for related changes to appear. This is my conjecture.

However, this causes a problem for me. I create keyboard shortcut through applescript or BetterTouchTool to invoke Menu Bar -> File -> Open With -> Certain App.

This way I programed FN+SHIFT+1 to open the file with TextMate, FN+SHIFT+2 for Writer Pro, etc.

The 1) need for cursor over "Open With" to trigger fetch, and 2) the delay in fetching cause my scripts to be invalid.

I was able to verify this theory by: 1) Right clicking a file, 1) Hover over "Open With" entry, 3) Wait for the submenu to fetch, 4) Click outside the Context Menu to have it disappear, 5) and invoke the keyboard shortcut.

And the shortcut worked.

So these are my questions:

1) Obviously, can I revert to pre-Yosemite behavior?

2) Does anyone have clever ways to open a file type with multiple apps on demand cleanly and efficiently?

UPDATE:

So far, I have one workaround, that is to create a Automator Service. Here is an example with TextMate:

I can run this without delay through 1) Menubar -> Finder -> Services -> Open With TextMate, 2) top level of the context menu, or 3) a keyboard shortcut if I choose to.

This comes with two caveats:

1) The items received into the service have to be in the broadest definition possible, e.g. files and folders. Finder doesn't recognized, for example, .plist files as documents. If you set the service to only receive documents, Open With TextMate would not show up when you want to use it on a .plist file.

2) Because of (1), this menu entry shows up on every item in Finder. It's innocuous enough if there is only one or two custom entries. If there is six or seven, this group of items is going to take over the context menu.

Solution 1:

I had a similar issue and the 'Fetching...' was taking many seconds. I just reset Launch Services with the following command:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -seed -r -f -v -domain local -domain user -domain system

Solution 2:

After things settled down (spotlight indexing is complete, a few reboots, using different user names), things have settled down and the "fetching" delay has gone away and the popup menu opens in less than 2 seconds are so. But some conditions (like mounting new disks) seem to make the delay increase again.

Resetting Launch Services from first comment DOES work, if the delay increases (/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -seed -r -f -v -domain local -domain user -domain system). While the command executes, you can see in the Console

LaunchServices: Begin database seeding"

and

"... Completed database seeding"

Sometimes it takes a whole minute to reset/rebuild! There are also several error messages in the terminal window when the command executes (e.g., registering Livecode application's community edition).

Putting the reset launch services command in something like Lingon and running it every so often may be way to go until Apple fixes the delay in some future update.

Solution 3:

I noticed this when I have a Time Machine disk attached that has not been used in a while. If the disk is asleep and I right-click, I see "Fetching" in the contextual menu. Then I hear the HDD wake up, spin for a second, and the "Open With" menu is finally populated.

When I don't have the external drive attached, I don't see this behavior.