deanishe

Not quite. What I mean is that your regexes only match one line (when the Amex one is fixed). So if you pass several lines into the script at the same time, only the first line will be matched. The rest will be ignored or passed through without being processed. You need a script to split the input into multiple lines and loop through them. Alfred had no native ability to split a single input into several and handle each of them individually, which is what you need. Something like this: import sys query = sys.argv[1] # equivalent to $1 lines = query.split('\n') # separate text into individual lines def process_line(line): """This function processes each line of input using regexes.""" # Processing code goes here # ... # ... transactions = [] for line in lines: processed = process_line(line) # your function that handles each line transactions.append(processed) print('\n'.join(transactions)) # combine parsed lines into single string and pass to next element You could also pass each individual line back into the workflow via an External Trigger, so it is processed by workflow elements, not a script. But in any case, I think you need a script to split the input into its individual lines and loop over them.

I'd say that's a matter of interpretation. From my point of view as a workflow developer, I'm setting a filepath as the arg within the alfredworkflow object. After all, that—and not the JSON—is what Alfred passes as {query} to downstream elements, such as the Debug utility in the workflow I posted. That Alfred passes a different value to File Actions (and ⌘C) than to downstream elements when arg is a JSON-encoded alfredworkflow object, rather than a simple string, strikes me as a quirk of the implementation. Why does passing arg to the File Actions list (or copying it) not count as being passed out of the workflow object? From my perspective, my workflow is done at that point, and there's no situation where Alfred not decoding the JSON would be the preferred behaviour. This seems to be an implementation detail, not a user-facing feature. In terms of performance, I don't think Alfred would ever need to decode more than one JSON object at a time, would it? I can't perform any actions on multiple items at once. That's cool. I'd just like to be able to use different Alfred features together that aren't logically incompatible. Now I have to choose whether to forget about File Actions in my workflow or back out a whole bunch of changes and move back to the way it worked under Alfred 2. And as noted, JSON-within-JSON is a bit funky.

Can you be more specific about that? The workflow uses my Python library, which should take care of gzip content-/transfer-encoding transparently.

That's the way you built it… I do this all the time with Alfred 3. It's a core feature of Alfred-Workflow and extremely useful for avoiding ridiculous numbers of elements in Alfred. In particular, command-line libraries like Click, Cobra and Kingpin allow you to automatically map environment variables to command-line options. That's a fantastic combination and lets you avoid a lot of duplication (i.e. adding a bunch of mostly-identical Alfred elements for every single action). (We've spoken before about the utility of being able to control execution flow from code instead of workflow elements, and this is a good way to do it.) From my perspective (I've already written the code to do it this way), I'd be happy if Alfred just parsed the alfredworkflow object in arg before doing the is-this-a-file test. That's what I consider a "bug", seeing as that's the official way to set variables from an item and I am passing valid paths as the arg encoded within the alfredworkflow object. But overall it would be simpler if there were a variables object within each item: having to insert JSON as a string within another JSON object is tricky, non-intuitive and not exactly elegant. In that case, mods would also need a variables key. And I believe it's also possible to pass other useful stuff via the alfredworkflow object, such as configurations for downstream File Filters (I've never tried this myself). With file:skipcheck the File Actions list opens, but Alfred passes it the JSON, not the arg extracted from it

Alfred 3.4 (850) type = file is ignored on feedback items when workflow variables are also set via arg (i.e. arg is a JSON-encoded alfredworkflow object). Run the following workflow or build your own Script Filter around the JSON feedback. You can hit right-arrow on the first item with a "plain" arg to access File Actions. File Actions don't work on the second item, however. Demo workflow. Script Filter feedback: { "items": [ { "title": "Path, no vars", "subtitle": "This works with File Actions", "type": "file", "arg": "~/Desktop" }, { "title": "Path, with vars", "subtitle": "This doesn't work with File Actions", "type": "file", "arg": "{\"alfredworkflow\": {\"variables\": {\"var1\": \"val1\"}, \"arg\": \"~/Desktop\"}}" } ] }

Updated with some Alfred 3 goodness. Now auto-reloads results when an update completes Auto-updates list of repos when settings have changed Better handing of remote/origin URLs Can handle more URLs (not just GitHub and Bitbucket) Add "meta" app `Browser`, which will open the URL in your default browser Clearer naming of applications in settings: app_1 -> app_default, app_2 -> app_cmd etc.

PHP/Python etc. all support regular expressions. They are all passed into the script, yes. But your regular expressions will all only recognise one line.

FWIW, you can enter ä/ö/ü by pressing ⌥U (for the umlaut) and then the letter you want the umlaut on (a/A/u/U/o/O etc.) ß is ⌥S.

That's the same issue. System Events gives you Process objects, not Application ones, so you don't have access to the application's dictionary/methods

Normally, they're in ~/Library/Application Support/Alfred 3, but if you sync your workflows between machines, they're in whichever directory you've configured as your sync folder (Alfred Preferences > Advanced > Syncing).

Here's an edited version. It doesn't work, but it shows you how to properly set variables. I don't think the workflow can work unless you run it for each line of input separately. Alfred doesn't let you process multiple items at once, which is what you're trying to do (i.e. multiple transactions). Realistically, I think you're going to have to write a script in PHP/Python/Ruby/JS to do the parsing, so you can handle multiple lines at once.

If you're having problems with a workflow, please post the workflow. Screenshots are not enough. The problem is most likely that you aren't actually sending any input to the Show Notification element, but without having the actual workflow, I'm just guessing.

Upload it somewhere and post the link. Dropbox will do.

It only took a few minutes. There's no script per se. It's just Alfred's built-in File Filter function. I just went to ~/Library/Caches/Metadata/Safari/Bookmarks (where Safari exports its bookmarks, and history), dragged one of the .webbookmark files to the File Types field, dragged the directory itself to the Search Scope, and—here's the trick—added kMDItemURL to the Fields list in the Advanced tab. (I ran the mdls command on one of the bookmark files to find the metadata field I needed.)

Javascript the language isn't so terrible (although its community is pretty demented), but Apple's JXA API is in many ways worse than the AppleScript one. @jaladuvar If I were you, I'd strongly consider doing the absolute minimum in AppleScript, and passing the data to a Ruby/Python/anything-but-AppleScript program as soon as possible.

I'm not sure I follow you. If you've got the frontmost process, you can script that object. What I haven't been able to figure out is how to get an Application object from a Process one.

If you found my unpublished Safari Assistant workflow, that isn't the same thing. The workflow I just posted was made especially for you. The other one doesn't search URLs.

You mean the URL? You can't search the URL via Alfred's default results, but you can with a File Filter by also specifying the kMDItemURL metadata field. Here's a workflow.

You'll have to be more specific if you want concrete help (i.e. post your workflow). Here's how to set variables: Fundamentally, it's not super-easy in AppleScript because you have to emit JSON. Using JavaScript (or basically any other language) would make it easier.

Ignore any processes with 0 windows?

You have a non-printing character in there. It doesn't say "LA check", it says "\x16LA check". Why didn't you post the workflow straight away? You've been told at least 10 times that screenshots are no help and you need to post the broken workflow.

I've been playing with this and found some weirdness: AppleScript calls go to the newer instance of the app, but JXA calls go to the older one: #!/bin/bash open -a 'Safari' 'https://www.google.com' sleep 10 # give app and page time to load osascript -l JavaScript -e "Application('Safari').windows[0].currentTab.name()" # Google osascript -e 'tell application "Safari" to return the name of the current tab of the first window as text' # Google # Open a new instance open -n -a 'Safari' 'https://www.yahoo.com' sleep 10 # give app and page time to load osascript -l JavaScript -e "Application('Safari').windows[0].currentTab.name()" # Google osascript -e 'tell application "Safari" to return the name of the current tab of the first window as text' # Yahoo

Compare PIDs. The lowest PID is the "original" app instance, the highest is the one you just created: // Compare PIDs function sortByPid(proc1, proc2) { var pid1 = proc1.unixId() var pid2 = proc2.unixId() if (pid1 < pid2) return -1 if (pid2 < pid1) return 1 return 0 } // Return array of processes, sorted by PID function namedProcesses(name) { var results = [] var procs = Application('System Events').processes.whose({name: name}) for (i=0; i<procs.length;i++) { results.push(procs[i]) } results.sort(sortByPid) return results } function run() { var procs = namedProcesses('Safari') console.log('oldest proc (' + procs[0].unixId() + ')', procs[0]) console.log('newest proc (' + procs[procs.length-1].unixId() + ')', procs[procs.length-1]) }

Very nice, but what is that icon?

Perhaps start a new topic there? It seems 99% certain that Adobe has broken things, not Alfred.