Jump to content

Multiple keywords to trigger the same script filter?

Recommended Posts

Wow - most underrated feature announcement ever-- This is great!


Do you know if the keyword1||keyword2 would work in variable substitution mode? i.e. set myVar = "apple||banana" and then set keyword trigger to {var:myVar} ?


Link to comment
Share on other sites

Posted (edited)

One small thing I noticed:


If you have multiple trigger keywords defined as "foo||bar", you can search "?bar" using Alfred and he will find the workflow, but typing "bar" in Alfred Preferences search does not find it (only finds "foo" or "foo||bar"). This is as of 5.1.2130.



Edited by luckman212
Link to comment
Share on other sites

  • 1 month later...
On 4/5/2023 at 5:22 PM, vitor said:

Starting from Alfred 5.1 (currently in pre-release), multiple keywords are supported.

This support still seems haphazard. I see that it is using the common || operator found in many programming languages. But now the keyword field cant use || as a keyword trigger ? Which I used to use for a custom terminal command. Why wasn’t the keyword updated to just support a list interface like list filters or similar. Where you can clearly define many keywords, not have to worry about them being slammed together into a tiny text field, and also not be restricted by character usage. 

Link to comment
Share on other sites

You may disagree with the implementation, but no feature in Alfred is implemented haphazardly. In software there’s always a tradeoff and shoving a list interface into every object that allows a keyword (it’s not just Keywords) would complicate both the interface (user side) and the framework (development side) for something which though highly desired is comparatively niche.

Thus we had to reach a compromise. One which both allowed the feature to exist but not be overwhelming (in multiple senses of the word). We arrived at the double pipe as the separator because it’s an incredibly rare choice as a keyword and makes sense due to its use in other contexts.

Ideally it wouldn’t clash with any use case, but realistically the alternative would have been for the feature to not exist at all. It’s no different to saying you can’t have your keyword be {var:something}. While technically correct, it being that way allows for much more powerful interactions in a greater array of cases.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...