Andrew

@GuiB This is dealt with by Alfred's workflow framework code, so hopefully fixing arrays / complex arrays for this case will also fix any other areas which weren't working

@GuiB just a quick update on this - I've raised an internal ticket as dynamic configuration of the 'Fields' part of the file filter needs a code update to work (looks like this has never worked). This would get the 'alt' connection path working in your example workflow. It also looks like variable replacement within [complex] config tables also aren't being correctly replaced, so I'll get that sorted too. Your workflow example was completely on point btw, it makes my job significantly easier! Cheers, Andrew [moving to bugs]

@nikivi You need to set the connection coming out of the list filter (the little circle on the connection) to "Don't close Alfred window on actioning result". This will change it to a square, and should prevent the window closing between the list filter and script filter.

@deanishe it does do result ranking (and latching) in a number of different ways using usage knowledge, but not closeness of typed query to match... so in answer to your question of how would regex be ranked, it would be ranked in the same way as Alfred currently does things in that if the result matches the regex (yes or no, not weighted), then it's passed along to the knowledge which subsequently sorts all the results.

@deanishe we may be talking about slightly different things... With script filters, Alfred doesn't do any magical ranking of 'closeness' of typed query to the result. I thought this was what you were referring to, and something I was saying could be interesting to take on as a future iteration. I now see what you mean, using Alfred's knowledge, you wouldn't want to drop/truncate results before looking at the knowledge. It may be best to just leave off the limit. Cheers, Andrew

1. Match can be terms or a string, and it will be OR'ed... so "term1" would match and "term2" would match, but "term1 term2" wouldn't match. But as I said, it'll take just a string so you could do either. 2. regex would take the user's query and match it against the title, or whatever has been populated in the match field. This would ultimately give you full control over which results match. 3. Not sure yet, but it'd likely be same as current sorting, at least in the first iteration (where it uses Alfred's knowledge). 4. (and continuation of 3) this is certainly something to think about, perhaps for a later iteration though as it adds quite a bit of complexity. Something I'd be interested in tackling though.

That's exactly what I was thinking.

... Thinking about this even more, the filter options may actually just go off a cog next to the "Alfred filters results" button, leaving the optional "match" field in the JSON.

So thinking about this a little more, when "Alfred filters results" is selected, it'll be something along the lines of a top level "filter" object which contains type, match and limit. The type would be "words" (default, as per current matching), "fuzzy" which matches the App fuzzy settings, and "regex" which would allow fully custom matching. If using regex, you'd populate a regex field too. Populating "limit" would stop the matches after this number of matches is met. Leaving this out would mean match on all returned results as per current matching Populating a "match" field per result item with either a string or array would define what each row is matched against. Leaving this out would default to each result title as per current matching. To switch the mode to match the title on how Alfred matches on applications, you'd use: { "filter": { "type": "fuzzy" } } An example of a fully populated filter in the JSON output could be the following, which does regex matching per result on the given terms. { "filter": { "type": "regex", "regex": "/someregex/", "limit": 40 }, "items": [ { ... "match": ["match term 1", "match term 2"], ... } ] } There is a good chance I'd also add a global workflow setting to change the default matching mode to "fuzzy" when the "filter" object is missing from the JSON. Cheers, Andrew

Interestingly, I can now see bookmarks and history in 10.13 Spotlight, but still can't see any filesystem metadata which is what Alfred uses to show these bookmarks. I'm wondering if the underlying metadata has changed in type - if anybody can find the metadata files (which were in ~/Library/Caches/Metadata/Safari/ pre 10.13), then they get a pretend gold star! Either way, I've now created a ticket to look at manually loading the plist for the bookmarks in case this isn't rectified by Apple.

@s4nji nicely spotted thanks - there seems to be a general issue with Caps Lock which stems from the way Alfred watches for multi key / dead key states with the text auto expansion. I'll take a look into this for the next release. Cheers, Andrew

@deanishe related apps isn't part of the designated migration, but I can see that this could be useful to be migrated. I'll add a ticket to look into this as this will be the first non-keyword, non-hotkey item migrated. Off the top of my head, I can't think of any reason this can't be included in the migration though Cheers, Andrew

@GuiB thanks for the workflow, I'll take a look into this once I finish what I'm working on and get back to you

I'm happy to improve the "Alfred Filters Results", I've opened a ticket. I like @vitor's idea of a filter field in the JSON which could define an array of match phrases. I've raised an internal ticket to look into this - be sure to @ me in here if you have any further thoughts or ideas Cheers, Andrew

@deanishe the behaviour in Alfred's default results won't change (and therefore the AppleScript behaviour for "search" won't change). The new "browse" AppleScript command will open the navigation window and just use string you pass, so you'll be able to add a trailing slash or not depending on what you want.