Quick open window

After a double-click on a script name in the Quick open window, the window is dismissed, the search and found files are lost.
Is it possible to change this behavior and keep the window open until we click on a Close button?
In some case it could be very helpful.


That goes against every other implementation of a quick open feature I’ve ever used. If you really want to open multiple items based on the same search string, command-click them to select multiple files.

My need is not to open several files at once.
I know how and when to use Command-click or Shift-click.

If you think it’s useless, it’s ok for me.

BBEdit’s stays open by default:

By default, the “Open File by Name” window stays open when you click the “Open” button. However, if you would prefer for it to act more like a modal dialog, you may do so:

But you can change the behavior with an expert preference.

And the state of the window when it was closed is saved, so your query is preserved.


Please explain to me why you want this behaviour. How would you use it?


Let’s say some terminology has changed in a library or an app you’re using in dozens of scripts.
To update your scripts with no confusion, you want to open only 2 docs at a time, side by side.
One to pick up the code an the second as the receiver.

In this case (and some other like this), you’ll be happy to find your query unchanged, giving you the ability to open the next file in the queue.

[I hope my bad english understandable ;)]

It seems to me that the core feature request is to retain the query and its results so that you can quickly summon the list again. Leaving the window open is not really needed, and I would argue that wouldn’t really work given that Open Quickly operates as a sheet when dealing with tabbed windows.

You’re absolutely right!
As I never use tabs, I haven’t thought about it.

That’s it.



Not on my system…


Witch version of SD?

Some files, in the Quick Open window, appear 2 times: at top and bottom of the list.
My guess is that those files are duplicated in the list because their name and their content contains the query.
Is it an issue?

Script Debugger 6.0.1 (6A180) on OSX 10.11.6

Here’s and idea: Would it be possible to add a button to the Open Quickly results window to “Show Results in Finder” Clicking that button would open a Finder/Spotlight search window with the same results displayed in Open Quickly.

This would make OQ a little more useful, as it would not just help open files, but locate where the various versions are stored.

While we’re at it, how about a Quickly Open button on the tool bar? (The more I use it, the more I like Quickly Open)

Same version here but on Yosemite.
As you can see on the screenshots above, everything is fine.
Did you check yours prefs?

What’s the benefit of a button to open Spotlight?
A “Show in Finder” button Would not be more appropriate?

I’m a big fan of open quickly too. It’s one of my favourite “icing on the cake” features of Script Debugger.

That said, note that (pace Mark correcting me) all it’s doing is running an mdfind and filtering out the results for scripts and script bundles. Should you, heavens forbid, be temporarily on a machine bereft of SD for some reason, you can achieve a quick-and-dirty** similar effect in Terminal with

mdfind "<search phrase>" | grep scpt

So, if I want to find all the scripts and bundles that I’ve, say, used any ASObjC in, I could do

mdfind "use framework" | grep scpt

on the command line.

** won’t capture .applescript plain text files, though

(Apologies if this is a double post, I replied to this via email, and it doesn’t show up as a post.)

A “Show in Finder” button Would not be more appropriate?

I think a show finder option (control-click on selected found files, maybe) would also be a really good idea. I had assumed it was already there, but I guess not.

What’s the benefit of a button to open Spotlight?

After you click the button a finder window would open with the spotlight search results, the same results displayed in the SD Quickly Open window.

From there you could easily locate, rename, move, duplicate as many of the files and their folders as you wish. The results of your search would be persistent (until you closed the finder window.) I would find this very useful, and see it as a closer integration between SD and the mac.

(Of course, it’s easy enough for me to throw out these feature requests like they’re nothing, but one thing I’ve learned is sometimes changes that I expect to be trivial are not and vice versa, so I just ask, and leave it to Mark, Shane, Matt, etc. to decide if it is worthwhile or doable.)

While you have the basic plumbing correct (Script Debugger uses the Metadata Query API rather then the mdfind command line tool), the search Script Debugger performs for open quickly is much more complex in order to support discontiguous result hits.

As far as I can tell, the Finder does not provide an API for creating a search window. And there is result filtering and relevance ranking happening within Script Debugger to avoid bogus hits which cannot be transferred to the Finder.

Adding a Reveal In Finder feature for individual search hits would be trivial, but anything beyond that is problematic (at least with the understanding of the Finder APIs I have at present).

The Open In Tabs preferences setting controls this. When checked, the Open Quickly window should appear as a sheet over any existing document window.

What your screenshot is showing is incorrect behaviour. Try as I might, I cannot reproduce what you are seeing here (presuming Open In Tabs is checked).

Show in Finder, along with persistent results would be just fine with me!

Also, how about a “Recent Searches” pop-up on the search field too?

(We AppleScripters are so needy and demanding!)

One of the complicating factors is that there are two different metadata search APIs. Script Debugger uses one (NSMetadataQuery and predicates) while Finder uses the other, older one (MDQuery). So although there’s a simple way of telling the Finder to show a search window, it would effectively involve building a separate search. I don’t know whether that would be trivial to do or not; I’ve never tried.