vitor

@derBingle That method seems fine, but I won’t add it to the list because it’s a bit hackish. For it to be added to the gist, it needs to be part of the app’s AppleScript dictionary and have both URL and page title support.

@roccitman Those instructions are old. DownVid had a different icon and Alfred was still at version 2. DownVid has changed quite a bit since then. I may introduce audio downloading natively, but have no ETA.

Looks like you might benefit from EVE more than from your current setup. But if you still want to go with your original idea, what you can do is save a .txt file and then tell Alfred to quicklook it. A Run Script with qlmanage -p /path/to/your/file should suffice.

There’s no such requirement. OneUpdater would be pretty close to useless if that were a necessity. It doesn’t care what you name your Workflows. It also doesn’t care if a user renames them, as it’ll still work. The reason renaming broke on your setup is that instead of hardcoding the Workflow details, specifically in my Workflows I make that info dynamic, by taking advantage of Alfred’s automated variables. For that to work, I also need to keep an organised repo, which I do. Doing it this way instead of hardcoding paths — which, again, is not only perfectly feasible but the intended way — means I can have a single OneUpdater node that I just copy from Workflow to Workflow without needing to change any details. So technically I’m not even using OneUpdater as designed, and instead taking advantage of that unrelated Alfred ability. With over 40 shared Workflows, that really helps on preventing mistakes. I do the creation manually. I never bothered with automating creation, just updating. With just over 40 Workflows and well over 700 commits, it’s pretty clear updating is over an order of magnitude more important. Multiple times I though I already had, but it appears I haven’t. Looking at it, I might remember why: they’re somewhat complex, and it’d take a while to share them and explain what they’re doing, for something that is pretty tailored for my particular usage and setup. I don’t think the ratio of complexity to general usefulness would be worth it. Not in text form.

Update. Fix for cards whose newest editions have no multiverse id. To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

Done. Update to the latest version to get it (⌥↩).

As per the instructions, where are the contacts located? Try also the file indexing troubleshooting.

Troubleshooting steps for duplicate contacts.

Update. Added paste options. Paste as a Markdown link or the name and URL separated by a colon. To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

Search for Magic: The Gathering cards by name with mtg followed by your search string. Press ⇧ or ⌘Y for a quicklook preview of the card, or ↩ to open it on the Gatherer card database. Download | Source

Três Mil.

To be clear, what I meant to be the takeaway was “don’t do /Users/username; do ${HOME}”. Everywhere. If you’d do $var, do instead ${var}. As a bonus tip, instead of `command`, do $(command). And in the process you’re making an already long (by your own admission) article even longer. Don’t stray — if you think something is noteworthy, write another post and link to it. The longer your tutorial is, the less likely it is someone else will read it. This is particularly egregious when you mention the vim plugin, which not only is completely irrelevant for the article, it’s irrelevant for the majority of users (especially newbies). Choose a license is a good resource to learn about the rights and obligations of each popular open-source license. Pretty much every license — unless it’s public domain — requires that you credit the original author. But crediting is always appreciated, and deliberately taking it away is incredibly frowned upon (and, well, illegal; that’s the point). Even on public domain licenses — the most permissive of all — you can’t simply claim the code as your own. There’s a common saying in graphic design: “good typography is invisible” (sometimes with the addendum “bad typography is everywhere”). Same is true of good/bad UI and everything whose goal is to solve a problem for a user. People rarely notice when everything goes smoothly; they notice when things are frustrating. That’s why (constructive) criticism is both easier and more useful. These mistakes were what jumped first. Hopefully, with each critic and fix your article will become better and better, until at one point it’ll be so polished the only thing left to comment is “I enjoyed reading this, and it was useful to me”. For something to be so good you notice how good it is, it needs to be so good that you understand why everything else is bad. These things are so rare and good, it’s not even (only) the content that teaches you, but the format.

I’ve only skimmed the article, so I have only a few tips: Avoid things users can’t simply copy and paste even on your own setup. Don’t do export GOPATH=/Users/nikivi/go; do export GOPATH="${HOME}/go". Be consistent. Don’t say /Users/nikivi on one line and ~ on the next. That’s confusing to users who don’t already have a solid grasp of ~ being their home directory. Even worse when ~ itself is volatile in meaning (quote it and it suddenly becomes literal). I recommend you do ${} instead of just $. It’s clearer for when you need it. Get in the habit of quoting everything you can, when shell scripting. Not doing so will come back to bite you fast. Don’t waste too much time telling us about your preferred editor and your setup. That’s the subject for another article. But especially don’t waste time talking about plugins that are irrelevant to the tutorial. Final tip: use ShelCheck. There’s a VSCode plugin for it.

Can confirm this is now fixed.

Here’s an example from a Workflow whose “Alfred filters results” is checked in the Script Filter, and no results are found: And here’s the result from a Workflow whose “Alfred filters results” is unchecked in the Script Filter, and no results are found: In the second case I’ve added a conditional that, when no results are found, produces a single invalid (can’t be actioned) result, informing the user. To me, this is an important feature because it: Informs the user their command ran successfully. Informs the user what was the query that ran. This is particularly useful when queries are slow to run (contacting a server) and you’re not sure if it’s failing for the previous query (so you should wait), or the latest one. In contrast, the first example is indistinguishable from a Workflow error. Sometimes when I get that result I purposefully type something else or check the debugger on my own Workflows to make sure nothing is broken. So my feature request: when “Alfred filters results” is checked in a Script Filter and it produces no results, output a message informing the user. Something generic like ““{{whatever query}}” produced no results” would suffice.