Andrew

This should now be fixed in the 2.7.2 b400 pre-release, available in Alfred's update prefs

The behaviour of this is now much more consistent in the 2.7.2 pre-release. Define always shows the typed word as top result, even if there isn't a match (as definitions may exist in Dictionary.app which aren't spelt correctly for Alfred's spelling corrections). The option to show results without definition is now consistent across the define and spell keywords, allowing for language spelling correction without dictionary installed. Cheers! Andrew

You should now be able to manually add and edit UTIs in the 2.7.2 b400 pre-release, available in Alfred's update prefs

This should now be sorted in the 2.7.2 b400 pre-release, available in Alfred's update prefs

This should now be fixed in the 2.7.2 b400 pre-release, available in Alfred's update prefs

This build is now in pre-release... locking this topic. Thanks for the help, peeps

Hi Jonathan, This ticket must have been mis-processed as I already have a ticket raised by you in the system from a while back but un-targetted... I have moved it forward to 2.7.2 so hopefully this will be fixed in the next release. Sorry about that! Cheers, Andrew

Hmm this isn't something I can fix as the menu level needs to be in front of Alfred, otherwise when you bring up the text menu in Alfred's text field, it would be behind. Spotlight seems to be doing something which hides the menu in Safari, let me look into it!

I'll add a ticket and look into this

Unfortunately, these two things are mutually exclusive... If Alfred is to work without taking focus from OS X, then he will no longer be seen as the "active app" in the same way as Spotlight works. What happens if you click the Alfred hat in the menu bar?

Possibly not, but I'm sure somebody will create an El Capitan theme once 10.11 is released

Now that Alfred's new website is out, and Alfred Remote update is going to be my next priority

This is a bit of a tough one as OS X is pulling focus and Alfred can't differentiate between that being a user action or OS X action. I have some ideas to work around this in the future though (but it involves a bit of an overhaul)

Hello amazing Alfred users! During this current dev cycle, I've made quite a significant change to the way Alfred focuses / activates, which means Alfred no longer takes 'active' from the currently focused app in OS X (i.e. the current app doesn't dim down while Alfred is visible). This fixes quite a number of quirks which have been getting incrementally more intrusive, especially for multi-screen setups, with every OS X release... The primary issue being where focus returns to the incorrect window when Alfred is shown then hidden. It also fixes rare weird launch behaviour, and windows flicking when they shouldn't. As this fix affects quite a few parts of Alfred such as the Clipboard History (pasting), Quick Look and Large Type, I'd like to release this beta build for people who are up for helping me verify that this doesn't break anything before doing a pre-release and real release. Grab the build from: build removed as now pre-release There are quite a few other fixes in this build so far, so I've updated the change log here: https://www.alfredapp.com/changelog/ No need to specifically test anything, just use the build as normal and let me know how you get on! Cheers, Andrew

There is now another post for this in the bug report forum so it will be tracked there for now.. http://www.alfredforum.com/topic/6008-outlook-15-email-as-attachment-is-put-in-drafts/ It looks like the AppleScript in MO is broken which means it goes to drafts.

Over time, OS X's focus behaviour has become more obscure when it comes to apps like Alfred .There should be a significant improvement to the focus behaviour in the next release as a part of a fix for this bug: http://www.alfredforum.com/topic/5986-incorrect-focus-when-using-alfred-clipboard-with-chrome-accepted/ Stay tuned! Cheers, Andrew

I'm not entirely sure why this is happening as things are working fine in the simulator, and it could very well be a temporary issue in 9b4. Either way, I'll have a new build of Remote out before iOS 9 is released

Are you using a 3rd party unzipping tool such as iUnarchive or iZip? If so, try using OS X's built in Archive utility as we have found that the 3rd party unzipping tools sometimes don't correctly resolve internal symlinks in an app bundle when unzipping which corrupts them. Let me know Cheers, Andrew

There is an interim download available for this... http://www.alfredforum.com/topic/5908-crash-after-preview-in-alfred-accepted/?p=36276

iTerm's AppleScript has changed over time, as has the application name (now simply named iTerm.app), so for now, you'll need to update the terminal AppleScript yourself in Alfred's Features > Terminal. Select the "Custom" option and then use something similar to one of the scripts in here: https://gitlab.com/gnachman/iterm2/wikis/Applescript or https://iterm2.com/applescript.html depending on the version you are currently using! Hope this helps (for now, at least). Cheers, Andrew

The stack shows a crash outside of Alfred's control, deeper within an OS X framework. Alfred already checks if the image is in memory / available then calls drawInRect, so this isn't a simple recoverable error. Having said that, the crash shouldn't be happening at this point. It may be worth temporarily creating a new user account, switching to that user and trying from there to see if there is something corrupt on your main user account. It might also be worth trying a full metadata reindex (shortcut in Alfred's advanced preferences, select the option to delete the .Spotlight-V100 folder) in case there is some bad metadata filtering through. Let me know how you get on! Cheers, Andrew

The good news is Remote works absolutely fine in 13A4305g simulator (fresh build in Xcode 7), so there won't be issues in the future I'll get iOS 9b4 installed on my iPad soon and investigate the old build, either way, I'll likely release an incremental build for Remote before iOS 9 is released.

Alfred Remote isn't doing anything naughty so it could be a bug in iOS 9b4, I'll get the latest bits installed and take a look at this later today

Screensaver with password is the best option and what I also use

Thanks for spotting this, I'll get this fixed in the next release