deanishe

This workflow is still in development, but it can browse Safari bookmarks just fine.
 
Keyword to search bookmarks is bm
 
Keyword to search/browse bookmark folders (what you want) is bmf

Use CMD+ENTER to open a whole folder of bookmarks in your browser.

And here's "Close Tabs to Right":  
   
 
// Close Safari tabs to the right of the active one. ObjC.import('stdlib') function run(argv) {   var count = 0,     safari = Application('Safari'),     win = safari.windows[0],     tabs = win.tabs,     currentIdx = win.currentTab.index();   // console.log('Tab ' + currentIdx + '/' + tabs.length + ' active.');   if (currentIdx == tabs.length) {     console.log('No tabs to close.')     return   }     var first = tabs.length - 1,     last = currentIdx;   for (i = first; i >= last; i--) {     // console.log('Closing tab ' + (i+1) + ' ...');     var tab = tabs[i];     tabs[i].close();     count++;   }   console.log(count + ' tab(s) closed'); }  
 

Put this in a Run Script Action with Language = /usr/bin/osascript (JS)
// Close Safari tabs to the left of the active one. ObjC.import('stdlib') function run(argv) { var count = 0, safari = Application('Safari'), win = safari.windows[0], tabs = win.tabs, currentIdx = win.currentTab.index(); if (currentIdx == 1) { console.log('No tabs to close.') return } // start at currentIdx - 2 due to 0-indexing in JS for (i = currentIdx - 2; i >= 0; i--) { var tab = tabs[i]; tabs[i].close(); count++; } console.log(count + ' tab(s) closed'); }

Iris
 
A workflow for Alfred 3.0 that allows you to quick search for a movie or subtitles.
 
The workflow script was built with Node.js and, believe it or not, you need to install it on your machine in order to run it.
 
How to use it
 
Movies
 
The shortcut to search for a movie is: ⇧ + ⌘ + i. Alternatively you can use the keyword: iris.
 

 
The alt key allows you to search for subtitles by selected IMDB id.
 
Subtitles
 
The shortcut to search for subtitles is: ⇧ + ⌘ + o. Alternatively you can use the keyword: os.
 

 
You can also search for subtitles by providing the file path. It will calculate the hash automatically and suggest subtitles for the same release.
 

 
Packal: http://www.packal.org/workflow/iris
Github: https://github.com/DONSA/iris-alfred-workflow

Now that this has been implemented in pre-release and I had a chance to try it, I can say that although the new node seems to work reliably and is very clear, I still miss the option to just call Alfred (as opposed to Alfred 3) from AppleScript. Reason being we still need to call Alfred 3 when making a call from outside an Alfred Workflow. I have a few workflows that allow the user to install macOS services and launchd jobs, and those will still need to be updated (and break compatibility) with new Alfred versions.
 
iTerm seems to accept both iTerm and iTerm2 when being called via AppleScript. Why not make Alfred accept bot Alfred and Alfred 3? If necessary, the call could even be changed from tell application "Alfred 3" to run trigger "trigger_name" in workflow "workflow_id" with argument "test" to something like tell application "Alfred" to run trigger "trigger_name" in workflow "workflow_id" with argument "test" minversion "3".

If you want to open URLs in a specific order, you shouldn't be using a bunch of Open URL Actions all connected to the same trigger. Fundamentally, that says "run these all at the same time", and now you're stuck fighting with it because it's specifically designed to do the opposite of what you want.

So here we are discussing nasty hacks and even adding new features to Alfred to make an asynchronous technique synchronous, when the smart thing to do is to throw it in the bin and look for a synchronous way to do it to start with.

Adding delays is a terrible idea. What if you want to insert a new URL in second position? You then need to change the delay on every other action but the first.
 
This shell script does precisely what you want and it's a lot simpler to change the URLs and the order in which they're opened: 
#!/bin/zsh   # URLs to open read -r -d '' URLS <<'EOS' https://www.google.com/ https://www.reddit.com/r/Python/ https://www.spiegel.de/ EOS   # Split string into array URLS=("${(@f)URLS}")   for u in $URLS; do   open "$u" done It'd be easy enough to adapt to reading the URLs from a text file or Excel sheet etc. The main point is that it's fundamentally synchronous (it won't open a URL till the previous one is done).

sys.stdout.write('your string here')
 
Or
from __future__ import print_function print('your string here', end='')

It's not completely arbitrary because Alfred can't include everything and this is very, very easy to do.
Add a Run Script Action Set Language to /bin/bash Put the following in the Script box: pbpaste You now have a Clipboard Contents Input.
 
Getting the clipboard contents in Python: 
import subprocess   def get_clipboard():     """Return clipboard contents as Unicode."""     s = subprocess.check_output(['pbpaste'])     return s.decode('utf-8')

It's not completely arbitrary because Alfred can't include everything and this is very, very easy to do.
Add a Run Script Action Set Language to /bin/bash Put the following in the Script box: pbpaste You now have a Clipboard Contents Input.
 
Getting the clipboard contents in Python: 
import subprocess   def get_clipboard():     """Return clipboard contents as Unicode."""     s = subprocess.check_output(['pbpaste'])     return s.decode('utf-8')

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. …?

This is when re-saving the Smart Folder usually helps. It appears to be a general issue with Smart Folders, rather than the workflow.
 
FWIW, there's a bug in Python on OS X that can randomly lead to many Python scripts failing. If you're having intermittent failures, especially if it's affecting other workflows, too, it's probably the Python issue.

Like this?

OneUpdater works by giving you a workflow with a single object you can copy over to your own workflow. All the code is contained within the object itself (i.e. no external scripts).

For a few technical reasons, that's the most sensible way to share reusable objects.

The problem is, you're taking "reusable" objects and copy-pasting them everywhere, which is precisely what you're trying to avoid by creating reusable objects in the first place…

So, to do this properly, you'd probably need to start with a program that understands info.plist and can update objects within it (that's where all your objects will be). And you'd need to tag the elements with their ID and version somehow (a code comment in a Script Box for any object with one, but the other types?)

That way, I can just run a single command in my workflow directory to update any such objects in info.plist without having to replace the objects (and their connections etc.) by hand in Alfred's workflow editor.

There's also the drawback that you're quite limited in what you can do with a workflow object vs a code library. Alfred doesn't just let you connect any old objects together, so there's no way that I could, for example, put Alfred-Workflow's fuzzy search in a workflow element because Alfred won't let you pass more than one item to the next action. It'd have to go in a file, so it can be run/imported.

All in all, if you could build a program that could update components stored as files and/or info.plist elements, it'd probably be pretty awesome.

I guess something like zplug might be a good template.

If you're opening the Large Type programatically, i.e. via a Large Type Output, not using CMD+L on a result, this is relatively easily done.
You can dismiss a Large Type window by clicking ESC. Therefore, you can close a Large Type window programatically by running a script at the same time as you open the Large Type window that sleeps for 2 seconds (or however long), and then simulates an ESC keypress.
In AppleScript: 

-- Wait 2 seconds delay 2.0 -- Simulate ESC keypress tell application "System Events" to key code 53Hacky, but it works. Mostly.

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.

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

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?

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.

I guess you're setting a UID on your result items?
 
Alfred intelligently orders your results based on your past behaviour. So if you select "Safari" a few times for the query "s", Alfred will show "Safari" as the top result. It identifies results based on their UID.
 
As long as you don't give your items a UID, Alfred should show them in the same order you emit them.
 
If you do specify a UID, Alfred will take over ordering results.

Have you set the quicklookurl parameter for the JSON result as a URL?
 
https://www.alfredapp.com/help/workflows/inputs/script-filter/json/
 
You can set and override the quicklook for any result with this parameter.
 
Cheers,
Andrew

I symlink my own workflows. Your code belongs in version control, not in an .alfredpreferences bundle in your Dropbox.
So that this works cleanly, for Python, I keep the actual workflow in a src subdirectory of the repo. That way, I can symlink the subdirectory to Alfred without the .git directory ending up in Dropbox, which isn't great. Also, building the workflow is as simple as zipping up the contents of the src directory. Keeps it nice and simple. When the repo root is the same as the workflow root, you have to be careful to exclude files during building. I've seen a few workflows that contained copies of themselves that contained copies of themselves that contained copies of themselves… because the author kept the built workflow alongside the source in his repo.
With Go, because it needs compiling anyway, I write a build script that puts the completed workflow in a build subdirectory, which can then be symlinked to Alfred or (its contents) zipped into a workflow.
I also keep all the code in external files and use Alfred's Script boxes like a shell to call the scripts. Alfred is a terrible programmer's editor, and you lose a lot of the benefits of git etc. if all your code is embedded in info.plist.
This has the overhead of an extra bash process, but that's about 0.01s when it isn't loading your dotfiles.
With regard to libraries like Alfred-Workflow, I don't think they're as necessary in Alfred 3 thanks to the ease of generating JSON compared to XML (at least in scripting languages). There's a lot more to AW than just generating XML/JSON, but with Alfred 2 you basically needed a library for the XML generation alone.
Finally, I generally write my workflows as command-line programs. If you have environment variables mapped to command-line flags, you can do some really neat stuff with workflow variables.

Create a new directory for your project with a "src" subdirectory. Create a new, empty workflow in Alfred. Configure the workflow's name, bundle ID, icon etc. in Alfred's UI. Reveal the workflow in Finder. Move everything to the "src" subdirectory of your new project. Delete the workflow from Alfred. Symlink your workflow from the project directory: workflow-install -s src workflow-install script.

Alfred doesn't expand snippets in its own query box.
 
TBH, I'd post that as a feature request. Would probably be very useful, and Alfred gets on just fine with other snippet expansion apps.

That was easier than expected, I added the features to the workflow Please give me feedback if it works as expected.

Hey,
 
for the first request I will have a look if the suggestion document gives me some kind of a language tag back. If that's the case a directional translation page will be manageable. The second one shouldn't be a problem at all Will try to keep you posted here what's the progress on this is.