Multiple keywords to trigger the same script filter?

[Chris Messina]

🔥🔥🔥

[luckman212]

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} ?

 

[vitor]

Yes, it works as a variable. Which means that if your workflow has user-configurable keywords, the user themselves can make that value have multiple keywords by using the ||.

[luckman212]

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 April 10 by luckman212

[Andrew]

@luckman212 ah thanks for spotting, I'll get this fixed in the next build

[luckman212]

Thanks for fixing! Looks like it works fine on 5.1.2133 🙂

[Terminal]

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. 

[vitor]

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.