deanishe

And can Alfred now find the file?

The File Types are UTIs, not glob patterns. Try dragging a .conf file to the list. It may or may not work, depending on whether there is a UTI defined for file extension .conf

Because you submit a pull request against source code, not the binary… External triggers live in info.plist. Accepting binaries in pull requests is not a smart thing to do. There could be anything in there.

You can drag applications from Alfred's results list, too. That's a lot faster than using a file dialog.

Why don't you submit a pull request after you've added external triggers?

The same applies to quite a few workflows. I think the best solution would be for Alfred to define a double-modifier (e.g. ⌘⌥) that shows the subtitle. Or, you know, turn subtitles back on if you use features/workflows that really need them.

Like I say, if the "python" command on your system points to Python 3, you're going to have problems with it. Python 3 should be called "python3".

They go in ~/Library/Application Support/Alfred 3/Plugins/Email I don't know anything about writing one, though.

Attaching files isn't a "standard" feature like addressing emails is. It requires an AppleScript plugin for the specific email program you're using. There was a plugin for Outlook, but I've no idea if it's still available or works with current versions.

If they're all in the same directory, or there aren't many templates, a File Filter would be simpler.

Your best bet is Alfred's 1Password integration. If you create a 1Password login for each account, you can launch them from Alfred. Regarding this and your other question on Outlook: Alfred is a launcher, not an automation application. It's for finding and launching things. The limit of its integration with other apps is (generally) passing them some data via macOS. You can create a script that does whatever with your application, and Alfred can run it (and pass it some data), but fundamentally Alfred doesn't know how to do anything with other applications other than pass them some stuff.

Hi @CincyTriGuy. Welcome to the forum. I'm afraid you're probably asking in the wrong place. This is 95% an Outlook question, not an Alfred one. That is to say, what you're talking about is automating Outlook, not Alfred. Alfred can certainly pass the selected files in Finder to your script that does all the Outlook stuff, but it can't help you with any of the Outlook stuff… The same is likely true of the forum members. You'd probably do much better to ask on Think Different or a forum dedicated to Outlook/Office. It's possible there's an Outlook automation expert lurking on this forum, but it's not their natural habitat.

That's likely the cause of the problem. The script is built for the default Python 2.7 that's a part of macOS (/usr/bin/python). It works on any normal macOS install. It's almost certainly not compatible with Python 3. If you have other Pythons, changing the shebang to /usr/bin/python should make the script run properly. If the "python" command resolves to a Python 3 on your system, you should really fix that. "python", if present, should always be Python 2. Python 3 versions should be named (or symlinked to) "python3". The two are not very compatible, so having "python" resolve to Python 3 will break most Python 2 code.

Add fuzzy search to your Script Filters This is a simple script you can add to your Script Filters to replace "Alfred filters results" with a fuzzy search algorithm. https://github.com/deanishe/alfred-fuzzy How it works Instead of calling your script directly, you call it via fuzzy.py, which caches your script's output for the duration of the user session (as long as the user is using your workflow), and filters the titles of the items emitted by your script against the user's query using a fuzzy algorithm. Example usage fuzzy.py only works in Script Filters, and you should run it as a bash/zsh script (i.e. with Language = /bin/bash or Language = /bin/zsh). Instead of running your own script directly, place ./fuzzy.py in front of it. For example, if your Script Filter script looks like this: /usr/bin/python myscript.py You would replace it with: # export user query to `query` environment variable, so `fuzzy.py` can read it export query="$1" # or if you're using "with input as {query}" # export query="{query}" # call your original script via `fuzzy.py` ./fuzzy.py /usr/bin/python myscript.py Note: Don't forget to turn off "Alfred filters results"! Caveats As the script is written in Python and uses a more complex matching algorithm, it can only handle a few thousands items at most before it becomes irritatingly sluggish (Alfred can handle many tens of thousands). If there's interest in the script, I will rewrite it in a compiled language. My Go library uses the same algorithm, and it can comfortably handle 20K+ items. You can grab a demo workflow from GitHub to see it in action. See the GitHub repo for more information.

Yes. This is the best way, imo. Alfred doesn't care about the name of the directory your workflow is in (AFAIK, the UUID is just a simple way to create a random name). Alfred identifies workflows by their bundle IDs. Dropbox also does the right thing when syncing. If the target of the symlink exists on the other machine, it re-creates the symlink. If it doesn't, it copies over the actual directory. The only gotcha with symlinks is that Alfred is a lot slower to pick up changes to info.plist if they weren't made via Alfred's own GUI. I have a couple of script to help with developing workflows. This one installs your workflow by copying/symlinking it to Alfred's workflow directory, and this one builds an .alfredworkflow file from a directory containing the source. The latter is primarily aimed at Python workflows, so it may not be optimal for workflows written in other languages.

You shouldn't use the settings API because each Workflow instance assumes it's the only one accessing the settings.json file and will overwrite changes made by other instances/processes running at the same time. It's a bad choice anyway: the settings are persistent data, meant to be kept as long as the workflow is installed. Such data very clearly belong in the cache directory. It's not as if Workflow.cache_data() is any harder to use.

Yup. Writing the status to a file is probably the best way. Another possibility is to start a server for your Script Filter to fetch the status from, but that seems like overkill.

You can read the "SOURCE PAGE X of 4" lines by capturing the STDOUT/STDERR output of the process. Here's a bit of code from a program I wrote that does something similar: proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) while True: if proc.poll() is not None: # subprocess has finished break line = proc.stdout.readline().strip() if not line: continue # parse output here

Thanks. I figured it's that workflow, but are we talking about the latest release or an unreleased dev version? To be clear, the workflow works perfectly for me, but I'm not running High Sierra because I don't run beta versions (or .0 versions) of OSes. I just want it to be clear which code you're talking about, in case somebody else can replicate the issue.

https://www.alfredapp.com/help/workflows/inputs/script-filter/json/ See the "text" section. Also the example workflow you can add via Alfred Preferences > Workflows > + > Getting Started > Script Filter shows most of what you can do (it doesn't demonstrate rerun or variables).

Yeah. If nothing is selected in the query box, and you haven't set a "copy text" for an item, ⌘C copies the selected item's arg. BTW: You might want to add a copy of the .alfredworkflow file to your releases on GitHub. People generally expect to find the installable files in releases.

Yay!

The whole "$ to copy URL" is unnecessary: just hit ⌘C on a result to copy the URL.

Literally four posts above yours: https://www.alfredforum.com/topic/1207-alfred2-workflow-for-google-search-suggestion-instant-search-and-current-site-search/?do=findComment&comment=41703

Where's the workflow that's having the issue? It's very difficult to diagnose an issue without being able to replicate it.