deanishe

AwGo — A Go library for Alfred workflows Full-featured library to build lightning-fast workflows in a jiffy. https://github.com/deanishe/awgo Features Easy access to Alfred configuration, including populating a struct from workflow variables and persisting settings back to info.plist. Straightforward generation of Alfred JSON feedback. Support for all applicable Alfred features up to v3.5. Fuzzy sorting/filtering. Simple API for caching/saving workflow data. Catches panics, logs stack trace and shows user an error message. Workflow updates API with built-in support for GitHub releases. Built-in logging for easier debugging. "Magic" queries/actions for simplified development and user support. macOS system icons. Installation & usage Install AwGo with: go get -u github.com/deanishe/awgo/... Typically, you'd call your program's main entry point via Run(). This way, the library will rescue any panic, log the stack trace and show an error message to the user in Alfred. program.go: package main // Package is called aw import "github.com/deanishe/awgo" // Workflow is the main API var wf *aw.Workflow func init() { // Create a new Workflow using default settings. // Critical settings are provided by Alfred via environment variables, // so this *will* die in flames if not run in an Alfred-like environment. wf = aw.New() } // Your workflow starts here func run() { // Add a "Script Filter" result wf.NewItem("First result!") // Send results to Alfred wf.SendFeedback() } func main() { // Wrap your entry point with Run() to catch and log panics and // show an error in Alfred instead of silently dying wf.Run(run) } In the Script Filter's Script box (Language = /bin/bash with input as argv): ./program "$1" Documentation Read the docs on GoDoc. Check out the example workflows (docs), which show how to use AwGo. Use one as a template to get your own workflow up and running quickly. Running/testing The library, and therefore the unit tests, rely on being run in an Alfred-like environment, as they pull configuration options from environment variables (which are set by Alfred). As such, you must source the env.sh script in the project root or run unit tests via the run-tests.sh script (which also sets up an appropriate environment then calls go test). Licensing & thanks This library is released under the MIT licence. The icon is based on the Go Gopher by Renee French.

Thanks for changing the links to GitHub, but you missed one near the top in the "Creating workflows with Go" section: it still says go get git.deanishe.net/deanishe/awgo. Could you change that to go get github.com/deanishe/awgo? Now I'm happy with the library, GitHub will become the official repo, and git.deanishe.net will just be a mirror.

The best value, imo, is export GOPATH=$HOME. That way, when you install a command (as opposed to a library) with go get ..., it's installed in ~/bin. All of what @vitor said. Plus: You link to https://github.com/deanishe/awgo for the library, but install it from git.deanishe.net/deanishe/awgo. Install it from github.com/deanishe/awgo, too. It's a mirror, and GitHub's servers are way more reliable than my cheap-ass VPS. Might be different? Must be different. No, it's required. AwGo is a bit more flexible in what it accepts (minor and patch versions are optional), but it won't work if you call your releases "dave dee", "dozy", "beaky", "mick" and "tich". This is broken in two different ways. Firstly, it will go wrong if "test" appears somewhere else in the URL, such as if someone would like to search for product reviews on https://www.test.de. Secondly, you aren't URL encoding the query. It won't work if a query contains "&", for example. Workflow code There's no reason at all to read the CSV into a map. All you do with the map is immediately unpack it into pairs again. There's also no reason for the links variable, as the only thing you do with it is pass it to the range call. Might as well just use ... range parseCSV() {.... Finally, the rest of the code is taken directly from one of my AwGo example workflows, only you removed my copyright notice (in direct violation of the licence). I do not appreciate your passing off my code as your own. Either link to where you got the "starter code" from, or put my copyright back into my code.

You can't. Only {query} works in the Script box. {var:varname} only works in other Alfred elements like Args and Vars or Filter utilities. You have to use system attribute in AppleScript, as described in the HOWTO. I'm not exactly clear on what your question is. If you want to pass a hardcoded value to your dynamically-configured script, put an Args and Vars utility before it and set the query to your path.

Haha! The Germans do that a lot, too. Almost none of them realise Mission: Impossible is based on a TV show, 'cos it was called "Take over, Cobra" here. And, there are about ten shows called "<name of main character> für alle Fälle". What a creative bunch they are.

It appears to be more like rvm/pyenv than a traditional package manager.

Please upload your workflow and post a link. Otherwise, it's just guesswork, which is largely a waste of all our time.

Heard the same, but the Haskell code I've seen looks harder to understand than even Perl. I've been wanting to learn a Lisp for much the same reason for quite some time. The books and tutorials I've found have all been too mathematical for my tastes

Is Haskell particularly suited to such a project? Or do you just want a reason to learn it? It seems like a fairly significant dependency, though I assume Homebrew has it. I'd imagine it would reduce the potential pool of contributors significantly, too, even if it would increase the average quality of pull requests. EDIT: Oh, I know that issue, too.

I'd change this line, tbh. This is used as the filename for the cache, so it needs to be filesystem-safe. If a query has / in it, it will crash. I'd suggest using the MD5 hash of the query, and no colons: import hashlib key = 'result-' + hashlib.md5(query.encode('utf-8')).hexdigest()

Thanks very much! Velozes e furiosos 8. Lol. Does that title sound as stupid in Portuguese as it does in English?

You're rewriting Homebrew-Cask, aren't you?

It doesn't block Alfred. Your long-running script should write its progress to a file, and a separate Script Filter then reads the file and shows the progress bar. You can open and close it as you please.

In that vein: do you know a search phrase I can use to check whether I'm getting Brazilian results vs Portuguese ones? I can hardly tell Portuguese from Spanish, let alone the difference between dialects.

You can create a progress bar in Alfred itself, using a Script Filter, rerun and variables.

Right. I thought you were talking about the UID. You're right. The language codes are wrong, and I'm certain there are more such errors. I will fix them eventually, but as noted, I haven't nailed down the format yet, so I'm not going to spend a few hours checking language vs country codes when it's likely that I might be redoing the whole lot anyway.

No, but it would be very easy to do with a workflow.

Contacts.app formats numbers for display. What you see is not necessarily what's actually stored in the database. Find a contact that's correctly formatted in Contacts.app, but not in Alfred, and edit it in Contacts.app. I think you'll find that what Alfred shows is what you've actually written in the phone number field.

They're country codes, not language codes.

Oh right, yeah. I forgot to mention that, which is pretty dumb of me, as I had to clear the cache many times while testing it… Glad it's working.

That is the impression I get. You're clearly not stupid. I wish you would spend a bit more time using your brain before using mine. Have you heard the expression, "make one to throw away"? A lot of coders, me included, appear better because they keep their first version entirely private. When it's mostly (or even only half) done, they see the silly mistakes they made. Then they throw it away and write a new, much better version now they understand the problem better. That's the version everyone else sees. I make lots of silly mistakes. The difference is, I fix most of them myself before I let anyone else see the code. Maybe 5-10% of my code is in public repos. The rest is in very dodgy prototypes that mostly work for me, but which I'd never release without entirely rewriting.

Use a Run Script action, not Run NSAppleScript. Then you can access workflow/environment variables.

If Chrome only puts text on the clipboard, there's not much Alfred can do. You could try simulating a right-click via AppleScript, but that's very error prone. Your best bet is provably a Chrome extension or a userscript. Also, your script is broken and shouldn't work properly. You need to URL-encode your argument.

I'll look into it. The updated URLs are present, however, so if you add the variables yourself, it should work.

Did you even look in the debugger? The first thing AwGo logs is your workflow version. It says 0.9, not 1.0. No, it doesn't. It downloads the second release. The one you've tagged "2". As you may know, 2 > 1.2. The docs are very clear about the fact that updates are based on (mostly) semantic version numbers. Your previous issue—forgetting to give your workflow a version number—is something that happens to everyone now and again (and as a result, I've updated AwGo to panic with a clear error message if you try to set an Updater for a workflow with no version number. Thanks for "finding" the issue). But this time, the log file tells you exactly what's going on: 21:33:02 update.go:166: Latest release: 2.0.0 21:33:02 update.go:211: downloading release 2.0.0 ... I'm sure you can understand how annoying it is for me to answer your questions when you haven't even tried to figure out the problem by reading the log file, and also post an error report containing entirely false information (again, because you didn't even read the log). I sincerely suggest you learn JavaScript, Node and alfy by @sindresorhus, instead of using Go and AwGo. It's fast—much faster than PHP/Python/Ruby, and I know speed is very important to you. The Go language itself is pretty simple, but the community and docs assume a fairly high level of programming competence. As a statically-typed language with pointers, it also requires quite a high level of attention to detail. By all appearances, you currently possess neither. JavaScript and its community are much more attuned to sloppiness.