Andrew

It's not quite this... it's just Safari is decoding the URL on entering it as this is the destination... so when you paste the URL into Safari, it's not re-encoding anything, it's just decoding the %20 back to spaces before re-encoding on passing to OS X to open in Alfred. There is definitely something a bit funky about Alfred's URL export, and I think it stems back to when Alfred required a pre-url encoded URL as the query part... which means the entire URL would be pre-url encoded and wouldn't need additional encoding. I guess another fix could be to just not URL encode the name when copying as this seems to work anyway (as long as you wrap the URL in quotes with the open command in shell). This may be the more correct fix, what do you think? Cheers, Andrew

I assume that when you use the open command, it is also encoding the %20 as literal, so %25 for the percent followed by 20, as this is the only way to make it a valid URL. Essentially, the only double encoding happening is when the URL is given back to Alfred (or the open command), and it's treating the entire URL as needing to be encoded as it has no better idea of what you want to do with it. The fix involves making Alfred aware of this on import, so will fix for the open command too.

Interesting observation! This may take a little bit of time as it will involve an architecture change to prevent a bodge fix so I'm going to move it to noted for now Cheers, Andrew

Sorry about the slow reply on this one, I can see what's happening here... Alfred is pre-encoding the name in the exported URL and when the URL string is then pasted into Alfred, the whole string is encoded again, so.. Search%20Just%20Watch%20%27%7Bquery%7D%27 is treating this string as absolute and correctly encoding the %s to %25 ready for passing to OS X to launch the URL... Search%2520Just%2520Watch%2520%2527%257Bquery%257D%2527 When importing, the %25 is correctly being decoded back to %... so it's essentially double encoding taking place. I've fixed this for the next release Cheers, Andrew

Could you give a little more info about your network setup... Do you use a proxy? Are you on a corporate network with filtering at all? Is there a firewall outside of your control which may be preventing the zip from being accessed? Essentially, the update plist comes from the same source as the zip file, so if Alfred is telling you that an update is available, then it should be able to download. Cheers, Andrew

Unfortunately, this is a bug in OS X's NSScreen API... I've attached a screenshot of the API call which Alfred uses, which doesn't return the correct screen when using full screen apps. Apple doesn't have a good track record of fixing bugs like this between major releases, so I guess it's fingers crossed in this case! Cheers, Andrew

Alfred doesn't interact with Chrome directly, he simply asks OS X to open the given (or created) URL in the default web browser. This is then subsequently passed on to Safari, Chrome etc. This is probably one you'll need to report to Chrome instead. Cheers, Andrew [moving to help forum]

The Open With action is essentially quite simple, using only native OS X calls, so I'm not sure why this would be hanging Alfred specifically with ImageOptim. Could you please reproduce this and while Alfred is hanging, open Activity Monitor, select Alfred and from the cog button in the toolbar, select "Sample Process". This may point me towards the issue! Also, does Open With work with other apps on your Mac? Cheers, Andrew

This indeed will be why you can no longer print to your wireless printer. I have no experience with this router so am unable to help, but did find this info on your router: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/NAT_Mode_with_Meraki_DHCP#Client_Isolation So it does look like your devices are isolated from each other. It also mentions "Bonjour" on that page which is the technology Alfred Remote and your Printer will use. Cheers, Andrew

Looking at the IP addresses, your iOS device and your Mac could be on separate VLANs. - What type of home office setup do you have? - Is your phone on a guest network? - Does your router have WiFi Isolation turned on (to keep devices separate)? Cheers, Andrew

This is configurable in Alfred's Features > File Search > Actions preferences [moving to help]

Before settling on Bonjour / Direct Connection, I spent a good few weeks investigating and playing with multipeer connectivity. I came to a few conclusions: - It was much more unreliable than Bonjour. This the same unreliability seen with AirDrop where it sometimes works faultlessly and sometimes doesn't work at all with the same network configuration. - When it did work, it sometimes fell back onto Bluetooth, which has very low bandwidth vs WiFi. One example of this is the initial setup where Alfred sends icons to remote took more than 30 seconds vs 1 second on WiFi. While this is something I will look into again at some point in the future, for now, Alfred Remote will continue to use Bonjour / Direct IP connection... Have you tried using the direct connection on your work network? Cheers, Andrew [moving to closed]

I'm unable to reproduce this - are you still experiencing the issue?

I wouldn't recommend using git for syncing the Alfred.alfredpreferences as Alfred (and workflows) use / modify this quite a bit and you may find keeping it in sync and conflict free being a huge pain. I'm not sure if you spotted this, but Alfred can dynamically sync your preferences if you have a syncing service such as Dropbox: https://www.alfredapp.com/help/advanced/sync/ Cheers, Andrew

I'm certain that you are right, but I wanted to err on the side of caution for now in my decisions for ATS in the short term to prevent any interruption in service. This will be analysed deeper in the future Cheers, Andrew

The file actions are due a big overhaul, so expect improvements in the future

Alfred's theming will be getting an overhaul in the future, and will give you much more flexibility for padding and spacings. That's all I can say for now Cheers, Andrew

I'm moving this to noted, but it's not a bug. Alfred's preferences app doesn't allow arbitrary loads, uses ATS, and this is the part of Alfred which does the auto updating. It's also worth noting that CacheFly was using TLS 1.0 at the point that ATS become relevant. I've worked with CacheFly and they have been very efficient in updating their CDN to use TLS 1.2 which allows me to remove the min requirement of TLS 1.0 for the CacheFly domain from Alfred's preferences making connections to any alfredapp.com domain / subdomain (for updating) use ATS. The reason Alfred allows arbitrary connections for domains other than auto updating with alfredapp.com is listed in one of the links you've provided: Essentially, there is no way for Alfred to know what domains Alfred's workflows need to connect to... much like a web browser, therefore HAS to allow arbitrary loads for network based workflows to work. This is currently a temporary exception and ATS will be fully enabled in Alfred in the future once the workflows catch up. Cheers, Andrew

I currently don't have a Mac I can upgrade to the 10.11.2 beta - would you mind trying a few things for me? 1. Is Spotlight working normally in split view (Alfred has a similar style window). 2. Have you tried Alfred again after rebooting your Mac in case there is a temporary issue in the beta? 3. If it's not working after a reboot, could you try the Focus compatibility mode in Alfred's Appearance > Options? Also, what version of Alfred are you using? Cheers, Andrew

It's unlikely that I'll add custom bindings, but If you weren't already aware, Alfred support's OS X's standard emacs bindings, so you can use e.g. ctrl+n/p for next and previous rows. Cheers, Andrew

Alfred has little control over where Finder decides to put the window... but I've found that if there are no Finder windows open and you use Alfred to show a Finder window, and position / size that window, the next time Finder shows the window, it will be in that position. Cheers, andrew

Could you show me a screenshot of Alfred's Features > Terminal preferences? The iTerm integration changed a few releases back, have you followed the details on this post which relates to two different versions of iTerm: https://www.alfredapp.com/blog/tips-and-tricks/better-iterm-integration-in-alfred/ Cheers, Andrew

Alfred works most effectively if you have less in the default results, then use the file search keywords for files: https://www.alfredapp.com/help/features/file-search/#file-search The quickest way to enter the file search mode is to show Alfred and then prefix your search with the [spacebar]. Cheers, Andrew

Hmm odd... any chance you could email me the info.plist of a workflow which isn't tab auto-completing? (the info@alfredapp address please) Cheers, Andrew

While there probably is something I could cobble together to defend against this scenario, it may have performance implications for the rest of Alfred to account for a (hopefully temporary) OS X error. A better solution would be to put something like this into a workflow: https://github.com/jhorology/bitwig-el-capitan-launcher Which is exactly what I've done for you here... https://dl.dropboxusercontent.com/u/6749767/Alfred/Workflows/Bitwig%20Launcher.alfredworkflow Drag Bitwig Studio.app into OS X's spotlight privacy preferences and type 'reload' into Alfred to prevent the original app from showing up. It's worth noting that launching directly stops the splash screen from showing, which is essentially what I think is causing the issue in El Capitan. Hope this helps! Cheers, Andrew