vitor

There you go. Either type divide followed by your number, or select/copy some text and press the Universal Actions shortcut.

Connect a File Action Trigger to a Run Script Action with the following in the Script box: mv "${@}" 'YOUR_ASSETS_PATH_HERE'. Replace YOUR_ASSETS_PATH_HERE with the path to the destination directory. You can get it by selecting the directory in the Finder and pressing the Universal Actions shortcut (the same you use to get to Copy To…) followed by Copy Path to Clipboard. Repeat that for as many assets directory you’d like to make specific shortcuts for. If you want to copy instead of moving, change mv to cp -r. The above won’t work exactly as you’ve asked. It will use the Universal Actions shortcut instead of you typing “move to assets” in Alfred, but this approach also works when navigating inside Alfred and is easier to implement.

I’ll take a pull request or an issue with instructions on how to fix it, but I haven’t messed with Electron in too long and it changes too much too often. Eventually I’d rather make it a Swift and SwiftUI (if it can even do menubar) app. No promises on a timeframe; Apple’s atrocious documentation is a huge turn off.

When searching files, having an hyphen at the start or end makes results disappear: Not the same as I don’t have that issue. Alfred 4.5 [1249] macOS Big Sur 11.5 (20G71)

Sometimes, the connection between two nodes can be moderately complex: That’s two checkboxes and a text field. If I want to move that connection to another node or temporarily disable it, I open it, save/memorise it, delete it, move it to another place, redo all configuration. I’d like to be able to move a connection to a different origin or end node easily while keeping its configuration.

Alfred 4.5 [1249].

Update. Added support for harakirimail.com and maildrop.cc. 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.

From the README (emphasis added):

It could go one further and allow specifying the dependency names. On Workflow install it could check for the existence of those packages and show a message if they’re not installed: “You’re missing dependencies for this Workflow. Install them with: brew install pkg-name” If the user does not have Homebrew, an extra sentence: ”To learn more about Homebrew, visit https://brew.sh” (or an Alfred documentation link). On the message there might be a way to disable the Homebrew requirement and continue using the Workflow, for advanced users. Still have to think of the advantages and drawbacks of this one. I though of the possibility of the requirements being binary names instead of Homebrew package names. The advantage of the former is that a user doesn’t truly need Homebrew installed, just the binary, but Homebrew package names don’t always map exactly to package names (making the automatic dependency message harder). Specifying the package name, on the other hand, allows for specific versions and taps to be set.

As mentioned above: It wouldn’t be a controversial decision (context: I’m a Homebrew developer).

If Alfred acted on the Homebrew installation, it could just run brew shellenv and use those values, no need to faff with any variables.

That already proves it was worth. I agree with @deanishe that developers who want to share with a wide audience likely won’t pick this up, but maybe there’s someone else who’ll also use it for Workflows within their team.

Homebrew itself doesn’t support non-standard locations. You can do it, but if you choose to you are on your own against unexpected behaviour (though PRs that would fix it are accepted). So Alfred wouldn’t even need the override setting and could point to Homebrew policy as the reason.

Method 3 isn’t an argument for having a global environment variable setting, but for Alfred to understand Homebrew by default. Those aren’t the same thing and I can see a stronger case for the latter (limited scope; greater control by Alfred; harder for users to screw up). The list of drawbacks is too short for that one; it wouldn’t require setup “once”, but (at most) once per Workflow to install the necessary tools. Either way, it’s not that different from telling a user to brew install whatever then having PATH set inside the Workflow with both Homebrew directories (/opt first). I remain unconvinced that a global environment variable is a better solution than that, given the drawbacks already listed by @deanishe. There’s a fourth method. It’s similar to method 1 with none of your listed drawbacks. That method is live in about a dozen of my Workflows and I’ve implemented it in other people’s with success.

I view that as an argument against the requested feature. A Workflow developer expects a certain tool to be available at a certain path, but because the user has overridden some global environment variable in Alfred, the wrong thing is executed and the Workflow doesn’t work. Different macOS or Alfred versions breaking a Workflow is understandable. A single setting doing the breakage inconsistently, not so much.