Andrew

These should now be fixed in Alfred 2.4 b274 available as a beta build: http://blog.alfredapp.com/2014/07/25/alfred-v2-4-yosemite-fixes-and-many-improvements/

This should now be fixed in Alfred 2.4 b274 available as a beta build: http://blog.alfredapp.com/2014/07/25/alfred-v2-4-yosemite-fixes-and-many-improvements/

This should now be fixed in Alfred 2.4 b274 available as a beta build: http://blog.alfredapp.com/2014/07/25/alfred-v2-4-yosemite-fixes-and-many-improvements/

Well spotted, I'll get this sorted for 2.4, thanks!

That could likely be a Dropbox issue or possible conflict if you ran Alfred before Dropbox had finished fully syncing to Yosemite. I'm not seeing an issue with that particular thing.

Hmm with a bit of playing, it looks like there is a fundamental change (or bug) with the way shared preferences (between Alfred and the Alfred Preferences app) works in the latest Yosemite release. I'm going to make some changes to work around this as I doubt this behaviour will be fixed or changed before the Yosemite GA.

I'll check this out once I update to the latest 10.10... but it could be a permissions issue. Could you try quickly creating a new user account on Yosemite, switch to that user and activate the Powerpack, then try switching themes there? Cheers, Andrew

That sounds likely!

I'm moving this to [investigating], but Alfred should work by mapping your hotkeys to the physical location on the keyboard. You may get quirks where the key displayed in the preferences is incorrect if you are switching keyboard layouts lots, but the actual physical key to trigger the hotkey should always be the same. Vero is going to get a few alternative layouts installed and have a look into this behaviour, but I know that there are other multi-keyboard users who this is working fine for (aside from the key displayed).

This option will be in the next release, enabled by default...

No problems at all... do any of your snippets use substitutions such as {clipboard} or {date}?

Hey there, just to chime in... I'm aware that this is useful and have added a ticket into my tracker so you can expect some improvements in a future release

Also, if you don't mind, any chance you could email your snippets database to info@alfredapp com... I can take a look to see if there is any specific issues. You'll find this in: Alfred.alfredpreferences/clipboard/snippets.alfdb Cheers, Andrew

Hmm, there shouldn't be a null pointer in this situation, but I'll add a bit of code in to make this more robust. I'm going to move this into bugs to keep a better track of this, but expect improved behaviour in this in the next release. For now, check your time and date format settings in OS X's preferences, as this is what looks like is indirectly causing an issue in Alfred. Cheers, Andrew

Alfred works on the basic premise that you have a keyword and an argument, e.g. the open keyword before a file search, or the google keyword before a search string. The only side case to this is the default file and app search where the keyword can essentially be empty, but the argument and matching is still the filename (search phrase). In your case, your best bet is to have a script filter with keyword 'create', then you have full control over any subsequent matches after this keyword, then make your script action create anything you like... e.g. create php project create rails project create new folder ~/Desktop/bob There are quite a few examples of workflows using script filters, take a look at the built in "Script Filter XML Format" example to see how to return results and suggestions into Alfred. Cheers, Andrew

Great, glad you are sorted

You are in fact setting a UID of '' in your XML... For Alfred to generate a random UID, you need to miss the UID field altogether... <item valid="no" autocomplete="Playlist▹spotify:user:trickyofficial:playlist:1u5vQfIxo8X1zoOInXxSGn▹"> This should fix the sorting issue you're seeing. The code / behaviour around this hasn't changed for quite some time, so it may have just been lucky that having all UIDs set to the same empty string would have sorted them arbitrarily correctly for you. Moving to [closed], but do let me know if this fixes your issue or not. Cheers, Andrew

Hi there, Alfred uses word boundaries when searching for folders / files and how word boundaries are treated is controlled by OS X's metadata server. It looks like the behaviour you describe also affects Spotlight, so if the word boundaries are being treated incorrectly, this could be an issue outside of Alfred's control. I'm going to move this to noted in case the behaviour changes in OS X, then I will check if Alfred is still affected. Cheers, Andrew

Ah nicely spotted, I'll get this fixed in the next release. I do plan on generally improving all the file actions in the future too, with better feedback.

The mechanism which controls this is really very simple in Alfred, so it should be reliable as it is for others. It could be that a 3rd party app is affecting this behaviour. Perhaps try temporarily creating a new user account on your Mac and having a play on that account to see if the behaviour is as expected. Cheers, Andrew

You'll find this is stored in Alfred's Features > Web Search > URLs / History preferences... select the entry and press backspace

Alfred resolves the symlink on adding by design for one very specific reason - performance. At the point you show Alfred, your set scope is needed. If Alfred needed to fully resolve all symlinks at this point, this could potentially be a time consuming operation, especially if there are network lookups to be performed. This would cause a temporary wait state in Alfred's interface every time you use it. I'll move this to noted as I can understand your use case, but for now, Alfred is going to continue to resolve symlinks at source. As a quick tip, in Finder's Open dialog, you can use shift+command+. to show hidden / dot files for selection.

Could you try temporarily creating a new user account, switching to that user and then trying again? If this seems to fix the issue, I'll walk you through deleting some of Alfred's caches in case something has gone out of control or become corrupt! Don't worry, we'll get to the bottom of this

This is actually by design as it helps normalise albums. For example, if you had an album from Eminem, Alfred chooses to prioritise this over a specific track on the album whose artist may be set as "Eminem ft. Dido". In your case, if the Artist field is set to "Isaac Delusion", Alfred would find this if the "Various Artists" field was empty. There is no benefit of having "Various Artists" in that particular field in your iTunes data, so if you clear out the Album Artist field from "Various Artist", Alfred will correctly find the artist "Isaac Delusion". Cheers. Andrew [moving to closed]

Theoretically yes, but there are key folders [deep] inside ~/Library which need to be indexed for Alfred and other apps. Alfred excludes ~/Library by default and includes specific folders automatically when necessary... so I wouldn't recommend adding ~/Library to Spotlight privacy. Cheers, Andrew