Andrew

@ericwen229 if you update to the 3.6.2 pre-release, then this should now work as described

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

If you update to the 3.6.2 pre-release, then open and fill should now work with the 1Password 7 general release

@nikivi this is likely to be a more major change, so won't be incorporated into a maintenance release. It is still on my internal radar though!

@huckncatch out of interest, from your initial question - when typing 'st', did you scroll down past the bottom of the 9 results and SourceTree still wasn't found?

Alfred will have a pre-release later today which will improve support, I'm just making a final few tweaks now that 1Password has been generally released

@dra Alfred requests a keyboard change the instant you use the Alfred hotkey, so has no control over the speed of the language change. In my testing, this has always been pretty instant, so I'm not sure what could be causing a delay for you. One thing you could try is setting the focus mode to "Compatibility" in Alfred's Appearance > Options. This makes Alfred work more like a traditional macOS window, so may change the behaviour. Also, make sure you don't have a conflicting setting in the macOS Keyboard > Input Sources > Automatically switch to a document's input source. Cheers, Andrew

@HRD I rolled my 1Password changes back out as the beta was broken for open and fill, then they reverted back to the old Safari extension... which should work again with the current version of Alfred (in my testing anyway). I'm continuing to monitor this situation though. Cheers, Andrew

@andrewsleigh this is macOS behaviour. Holding a modifier key such as cmd while typing a character will be interpreted as a shortcut combination, not a typed character.

I essentially have this fixed for the next Alfred build (aside from some quirks which I reported back to 1Password). I'll likely have a pre-release build out next week Cheers, Andrew

@andrewsleigh temporarily try using a different hotkey for Alfred to see if this behaviour is linked to cmd+space on your Mac. Cheers, Andrew

@Bhishan there are a few options for this. You can either set a suffix per collection (e.g. a space) so all snippets in that collection will only expand if followed by a space. Double click on a collection name in Alfred's preferences to add a suffix. Alternatively, you can simply add a space to the keyword for the snippet e.g. "\\a ". Cheers, 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?

@lewis42 Alfred doesn't upload anything at idle by default. If you restart Alfred, do you see upload activity or do you only see it while using Alfred? Some workflows (e.g. ones which go to the internet to get suggestions to present) may be causing the network access while using Alfred. Cheers, Andrew

@Gary King You shouldn't need to restart Alfred for a file filter to start working. To clarify, does the file filter (placeholder) show in Alfred, but then no file results are returned when you type the query? One interesting thing is that the macOS metadata index actually caches queries, and it can take a few moments for the differently formulated query syntax of Alfred's file filter to be interpreted and cached by macOS (it's usually instant). If you type your new file filter query, wait a few moments, hide Alfred, then re-show Alfred and re-type the same query, do you get results? You could try doing a full reindex of your Mac (shortcut in Alfred's advanced preferences), which may flush out indexing issues such as this. Cheers, Andrew

This is something I've known about for quite some time, and has been discussed in various forms a few times. The reason I've left this as default AppleScript behaviour of copy when external drive (at least for now) is because this forms a safety net should something happen. When moving on the same disk, the reference is simply updated, and no file is actually physically moved and no file data is changed. When moving to an external drive, the physical file is written to the new drive and the new drive will report back that this is "successful", but there is a chance that the file has been written to some bad sectors and by automatically deleting this file from its origin, the file is now lost. This is essentially why Finder's default behaviour changes to copy (unless you force it with cmd), and AppleScript changes the move command to a copy command automatically. I'm still on the fence as to what to do with Alfred, but I do agree with Dean that a move should mean a move. Cheers, Andrew

I've popped an email to 1Password for more info Cheers, Andrew

This thread has made me take a fresh look at how Alfred deletes snippets, and I've made a change to now move to trash for both snippets / collections and workflows instead of removing them. This will make it into the next Alfred release

I'm moving this to Discussion and Help as this will be a macOS metadata issue. I've also updated the title. Cheers, Andrew

@ericwen229 sorry about the slow reply on this - I have been thinking about this. Essentially, workflow streams and objects (and in fact Snippets) work with plain text only, so when using e.g. the Copy to Clipboard object, this is copying plain text to the clipboard (never rich text). I think you're right that {clipboard} should be evaluated to an empty string if there is no matching compatible plain text string. I'll get this sorted in the next release Cheers, Andrew

@QuaCKeReD if you open Alfred's preferences to the workflows tab, select the workflow which isn't working and open the debugger, is there any information shown when trying to use the workflow and the items not appearing? Also, perhaps try opening Console.app and see if any information is logged when items don't appear.

@vitor this seems to be a bug in the latest release of macOS 10.12 - it's still working fine in macOS 10.11 and 10.13. I'm going to be raising a bug report to Apple.

This should now be sorted in 3.6.1 b910 Cheers, Andrew

Alfred Remote will be receiving a big "Version 2" update, I'm already planning the feature set and improvements. It's also worth noting that we've been adding features to Alfred Remote through added objects within Alfred itself, so while Alfred Remote hasn't had a core update, it has had new abilities added over the past few years. Cheers, Andrew

@artem this is actually fixed in the 3.6.1 pre-release, and is specific to newer versions of High Sierra. You can update the Alfred 3.6.1 pre-release in Alfred's update preferences Cheers, Andrew