deanishe

No, I haven't changed anything since the initial proof-of-concept. Unfortunately, DFX 5 didn't work on my main Mac, so I had to uninstall it and re-install DFX 4, which isn't 100% compatible in terms of what the workflow does, so I didn't want to change anything and risk breaking the workflow for DFX 5 users. I've just installed DFX 5.0.5, and that runs acceptably well (mostly), so I can continue working on the workflow now. So, feature requests: Get rid of the notifications. …?

At any rate, I suppose Script Filter results should behave the same regardless of whether an argument is required or not and regardless of whether they're a top-level or a nested Script Filter. So, yeah, I'd say it's a bug and worth reporting.

If you wrote the framework, you can intercept the input from Alfred and show whatever you want. Set valid=false and arg=alfy:runscript:name-of-script.sh (or whatever) and have your library extract and handle such commands before calling the workflow proper.

PHP starts up more slowly than Ruby/Python because it's monolithic. As soon as you start importing the libraries you need to write something non-trivial, the difference shrinks or disappears.

Goddammit. I've spent the last few days messing around with External Triggers and AppleScript to glue my current workflow together. Now I'm going to have to remove all the grubby, little hacks and rewrite it all using this faster, more powerful, more resilient and all-round better method, instead. Thanks, Andrew.

Alfred's letting you action an item with no arg? Is valid also unset? If so, that sounds like it might be a bug. If neither arg nor valid are set, the item should be unactionable.

EDIT: For anyone reading this post, it's wrong! This is what Alfred-Workflow does, not Alfred. You must set valid=false to make a result item unactionable! I think that the incorrect assumption is that an empty arg is equivalent to no arg. It's not. If you do not specify arg in your JSON (or XML), then you have an unactionable result. If you set arg to an empty string, then you just set arg to an empty string… The item is actionable, and Alfred will dutifully pass along the empty string to the next action. The same goes for autocomplete (if it's an empty string, TABbing deletes the query back to the keyword). Setting valid to false should do the trick, but as noted, ensuring arg is not set at all (as opposed to set to an empty string) gives you an unactionable result. So, if any authors of Go libraries for Alfred are reading this: Yup, you've done the JSON wrong, and you'll have to rewrite using pointers to strings

As a rule of thumb, don't use NSAppleScript without a good reason. Use a normal Run Script Action with Language = /usr/bin/osascript (AS) instead. The latter is run in the background like a normal script. NSAppleScript is run on Alfred's main thread, so it will block Alfred. Because you're calling from another application, rather than a GUI-less background command, it may also do weird things with focus etc. AppleScript is a weird beast, and some things fail utterly in a Run Script Action, but work in a Run NSAppleScript one. But try to get it to work as a Run Script Action with /usr/bin/osascript (AS) first.

I've been using Go a lot recently, and there is definitely something to be said for compiled languages and workflows. Go and Objective-C/Swift run about 20x faster than scripting languages, and the programs start up a lot more quickly, too. That gives you a lot of headroom to do things that would be too slow in a scripting language (or to avoid some of the complicated workarounds we use to manage the slowness).

It's daft not to read the docs. It takes a couple of minutes to read the --help or manpage, but hours to days to get an answer on a forum. Glad it's working.

The documentation for open (which you should read before you start making screenshots and posting questions): $ open Usage: open [-e] [-t] [-f] [-W] [-R] [-n] [-g] [-h] [-b <bundle identifier>] [-a <application>] [filenames] [--args arguments] Help: Open opens files from a shell. By default, opens each file using the default application for that file. If the file is in the form of a URL, the file will be opened as a URL. Options: -a Opens with the specified application. -b Opens with the specified application bundle identifier. -e Opens with TextEdit. -t Opens with default text editor. -f Reads input from standard input and opens with TextEdit. -F --fresh Launches the app fresh, that is, without restoring windows. Saved persistent state is lost, excluding Untitled documents. -R, --reveal Selects in the Finder instead of opening. -W, --wait-apps Blocks until the used applications are closed (even if they were already running). --args All remaining arguments are passed in argv to the application's main() function instead of opened. -n, --new Open a new instance of the application even if one is already running. -j, --hide Launches the app hidden. -g, --background Does not bring the application to the foreground. -h, --header Searches header file locations for headers matching the given filenames, and opens them. -g, --background Does not bring the application to the foreground. Sound like what you want?

Right-click on a workflow element in Alfred's workflow editor and choose Edit Note…

Apparently in node, console.log() writes to STDOUT, so that is the input to the next action.

This is a really old workflow and has Alfred 2 paths hard-coded. You need to edit the alfred.py file in the workflow and change Alfred 2/Alfred-2 to Alfred 3/Alfred-3.

Have you tried encoding a video with HandBrake/ffmpeg? That usually does the trick for me. I don't recall ever experiencing lag on my MBA, which has a 128GB SSD, versus 1TB SSD + 4–9TB HDD on the Mac Pro, so index size/latency might also be factors?

When Alfred runs your code, any output to STDERR ends up in the debugger and any output to STDOUT becomes the input for the next action. If I've understood you correctly, you need to redirect STDERR to STDOUT.

AFAIK, Chrome doesn't officially export a list of its tabs that Alfred can read (like 1Password and Safari do with their bookmarks), and I don't think Andrew would consider adding anything to the default results if Alfred has to query the application for the data, not load them directly from disk. The reason is that it can take 100x longer to ask an application for data versus loading them from disk, and that's in the best case scenario that the application responds as quickly as possible. Here's a concrete example of asking Safari for a list of its tabs versus loading a list from disk (using Go and JXA): From App From Disk 20 tabs 0.65s 0.004s 50 tabs 0.94s 0.012s 100 tabs 1.5s 0.022s

Does Alfred run workflows at a lower priority? I've always assumed this is why it (and Sublime Text) seem to suffer more than most other programs I regularly use when the CPU is maxed out.

I think Alfred has had this issue for a while, hasn't it? Not a good solution, but I use cpulimit to cap the rendering process and leave a few CPU cycles for other programs. I use Sublime Text a lot, and it will barely run at all if CPU usage is high.

Can you upload the workflow somewhere so we can have a look at it?

I use this build script for Python-based workflows. They core operation is zipping everything in the src folder without a root folder in the zip archive. With Python, you should also exclude .pyc files, as they are specific to the (minor, I think) Python version you're running. The script also pulls the workflow name and version from the source code to automatically name the generated file, so I can usually just run workflow-build src Also, I forgot about my cookiecutter template. That's what I usually use when I start a workflow these days. Then I symlink it to Alfred and add the icon etc. in Alfred Preferences.

That's really a question for the Marked support page. Pandoc can probably do it from the command line, although you might have to use pandoc to convert Markdown -> XXX and some other tool to convert XXX -> PDF.

I'll look into the problems tomorrow/Friday. I can't replicate the issue at the moment because I'm running the (currently) half-baked v2 rewrite that doesn't yet support the problem engines. I also need to reinstall Alfred 2 to edit the workflow to maintain compatibility. Unfortunately, simply editing a workflow in Alfred 3 will make it incompatible with Alfred 2, regardless of whether you use any Alfred 3-only features

Google says "yes". http://superuser.com/questions/666605/osx-mavericks-keyboard-shortcut-to-kill-notifications

As far as a comparison with Alfred goes, the only thing you need to know is that Flashlight doesn't work on anything but Yosemite. Flashlight is dead.