No results for file filter when deleting a character from keyword to match different keyword [Fixed 3.6.2 b914]

[Gary King]

I have two File Filters that are similar. They each essentially return the same file types from the same folder, except for a few file type differences. One keyword is "p" and the other is "pr".

 

If I type "pr test" then I have some results appear, as expected. if I delete the "r" from the keyword so that it appears as "p test", then no results appear. I have to modify the search, such as by simply adding a space somewhere, before results appear correctly for "p test".

[vitor]

Curious that you opened this, because just today I noticed something similar. It used to be that if we had two script filters with the same keyword, invoking one would also invoke the other. That seems to no longer be the case.

 

I should also open a report about that, after further testing, but both issues are likely related.

[Andrew]

@Gary King interesting find! I've been playing with this today and this is an issue which comes about by two bits of logic which Alfred uses to increase efficiency. Alfred uniquely runs file filters as this prevents issues with the macOS metadata server (it used to crash if inundated with queries).

 

What is essentially happening is the first file filter (pr) is still holding on to being the currently run filter when deleting the 'r' and attempting to run the (p) filter. As filters are checked sequentially, it's just unlucky in this case that the (pr) filter is being sequentially started after the (p) filter, and therefore hasn't released itself.

 

I've fixed this for the next build by pre-checking if the previously "current filter" is still valid in the workflow object pre-processing, and releasing itself if not.

 

@vitor two script filters with the same keyword should still be able to be run concurrently. I've just tested this and it seems to work as expected. There are a few deliberate exception cases to this. If you have the argument set as required and press return on a partially typed keyword, it will lock the results to this specific object. This is general behaviour in Alfred, and has been around for years... a good example of this is if you type "ope" for the open keyword, then press return on the "Open File" result, then all other results will disappear ready for you to type your file query.

 

Is there another scenario where script filters aren't running concurrently as expected?

[vitor]

20 minutes ago, Andrew said:

If you have the argument set as required and press return on a partially typed keyword, it will lock the results to this specific object.

 

It seems to also happen if the argument is optional.

I thought this wasn’t the case before, but it’s likely a result of not having tested that interaction enough. I was counting on it for the Script Filter behaviour of OneUpdater.

The behaviour of only running the one that was selected on a partial match makes sense, so I’ll think of another solution. So far, shortening the keyword for the OneUpdater Script Filter seems like the best option.

[Andrew]

@Gary King you should see improved behaviour if you update to the 3.6.2 pre-release