Andrew

Interesting, thanks! I'll add a ticket to look into this / keep it in mind, but as we still support 10.6, the terminationHandler isn't currently a holistic solution... I could just make this a 10.7+ only fix but it may lead to unexpected or difficult to debug workflow behaviour for some workflow creators.

You are correct, Alfred doesn't use waitUntilExit, he waits until stdout pipe is closed. When I originally used waitUntilExit (Alfred v1), I was seeing hanging / performance issues which ultimately affected the perceptual speed of Alfred. I switched to stdout closing as a marker of being done and haven't seen a performance issue since. This may no longer be relevant in newer versions of OS X and whatnot, but as there isn't much of a call for this, I'm reluctant to make any change in this area. Cheers, Andrew

It's unlikely that I'll be changing Alfred's behaviour as intrinsically, Alfred waits for a process to finish to gather the output from it. Sub daemon process behaviour is controlled by NSTask. I'm going to move this to noted, but for now, I'm not going to treat this as a bug (especially since there is a workaround).

Alfred is doing an extremely simple API call for 'get icon for /Applications/1Password.app' or 'get icon for /Applications/1Password 4.app' using: [[NSWorkspace sharedWorkspace] iconForFile:path]; He isn't looking at any deeper files within 1Password, just showing the icon OS X passes to him. The interesting thing is, OS X is actually passing a broken app icon which (as far as Alfred is concerned) is a valid icon, else Alfred would fall back to his own internal 1Password icon. If you delete 1Password, then restart Alfred, does the correct icon show?

Try renaming the app to 1Password.app (which is the default name for 1Password 4 in the app store anyway). This may clear through any issues

Alfred doesn't cache this icon, he simply shows the icon provided by OS X, so there will be something preventing this from happening in OS X on your Mac. If you select 1Pwd in Finder and use 'Get Info', does the icon show correctly there? Cheers, Andrew [moving to help sub-forum]

App-nap isn't relevant to Alfred. If you disable clipboard history and don't have any context sensitive hotkeys (v2.3), Alfred will be using 0% CPU at idle. Cheers, Andrew

Alfred doesn't keep the snippets database open, he only opens it when you need it so there is no 'reloading' which needs to take place. If the snippets database is correctly synced between the two accounts, Alfred will see the correct one. This could be one of a few things, it could be a dropbox sync conflict / folder error which is getting in the way. It could also be something to do with the user folder itself, for example a non standard symlink for a changed home folder. It could also be Dropbox not having enough time to sync the database up before you switch accounts. If you have two accounts on the same mac, you may be better off having a folder which both of your user accounts have access too and setting the sync folder to that in Alfred. This would cut Dropbox out of the equation and there would be no syncing to be done, just Alfred on both accounts sharing the same preferences. [moving to the help sub-forum]

Hi there, Thanks for spotting this, it looks like Genres isn't correctly diacritically flattened when searching. I now have a ticket in my bug tracker so will get this fixed in the next release Cheers, Andrew

Are you using a workflow for this? By default, the built in open keyword (or ' prefix) only searches title and the 'in' keyword only searches content. You may need to setup a workflow file filter if you'd like to search for both. If you are already using a workflow, could you share the workflow for us to take a look?

Alfred doesn't migrate or change his preferences on update, so updating is no different to restarting Alfred. Do you have any 3rd party tools installed which clear preferences on uninstalling an app? It could be that this tool is thinking the update is an uninstall and deleting Alfred's preferences. [moving to help sub-forum]

From the clipboard history viewer, if you don't want to paste the selected item, just use cmd+c instead and it will just copy that item to the clipboard and hide Alfred.

Alfred doesn't search on the path like in your first screenshot, so this must be something specific to the google chrome apps... google may be tagging or commenting them in a specific way for Alfred to be matching that. Drop one of the google chrome apps into this tool and let me see the output, this will tell us why it's showing: http://cachefly.alfredapp.com/tools/AlfredMetadataTool_v1.0.zip

From this and your snippets issue, it seems that there is a permissions issue or some corruption somewhere. Could you please first set your sync folder outside of Dropbox such as ~/Documents and then test both your snippets and changing the keyword for define to 'd' and report back.

Have you checked that Alfred is set to show on active screen in Alfred's Appearance > Options?

If this has only just started, have you tried just rebooting your Mac? There may be a quirk (e.g. if you are using Dropbox for syncing) which is preventing Alfred from accessing the snippets.

Alfred's clipboard merge mechanism is actually very simple, it just watches for subsequent duplicate entries in the clipboard with an incremental OS X clipboard count number... So you may likely find that Total Terminal is setup to automatically copy things to the clipboard on selection, so what's happening is you are selecting some text and TT is putting it in the clipboard, then you are typing cmd+c which is putting it in the clipboard again which Alfred recognises as a double cmd+c and merges. If merge isn't working some other times, do you have something installed such as Popclip or Textmate? These both use the clipboard mechanism and can interfere with the OS X clipboard counter. [moving to help sub-forum] Cheers, Andrew

If you select the top 'All Snippets' item, is that empty?

If you open Console.app, do you see any errors listed there? Alfred doesn't provide any network APIs to workflows, so this issue will be outside of Alfred's control. Do you use any 3rd party firewall or a network proxy which could be getting in the workflow's way? [moving to Workflow help]

That looks like the define keyword isn't sticking as 'de' shouldn't match at all if the keyword is set to 'd'. If you have syncing setup, it could be a sync conflict which has prevented this keyword from setting correctly. If so, you could try rebooting your Mac, or setting the sync folder to a different folder. Essentially, the reason I suggest setting the keyword to d is because it doesn't matter if it's not at the top, you can just keep typing i.e. d banana.

Alfred will learn that sa means Safari (and latch this keyword to the app), but if you want more relevant results by default, change the fuzzy mode in Alfred's Advanced preferences back to the default "Fuzzy capital letters", then sa won't match Skype at all. Cheers, Andrew

As Alfred asynchronously access your contacts, the only place this hang can be happening is in the Contacts API. It could be that it's hanging on trying to show you the request contact access dialog, but this dialog (presented by OS X) isn't actually showing for some reason. Try resetting the contacts security pasting the following into Bash and then restarting your Mac: tccutil reset AddressBook (source: http://stackoverflow.com/questions/11911719/how-can-i-reset-contact-access-permission-so-the-os-will-ask-again) [moving to the help sub-forum] Cheers, Andrew

If you open the clipboard viewer (using the clipboard keyword), do you see your snippets in there? [moving to the help sub-forum]

The fundamental reason Alfred doesn't provide this kind of search by default is that the OS X metadata server doesn't have context of the path as part of the search parameters, he only knows the path as part of the results returned to him. For performance (including memory) reasons, Alfred asks OS X for the most likely matches for a file given a set of constrains and knowledge, which is a subset of all matches (which could be thousands). As such, he can't subsequently filter through the paths and return the items you want as this would inevitably be missing some which didn't make the initial cut of results. i.e. you may have 1000 files named 'cafe', but Alfred is only getting the first 50 most likely matches from OS X and could only then filter through the paths for that. This would lead to confusing behaviour as the file you are looking for falls in the 950 which didn't match most likely and therefore you get no results. One fix could be that Alfred does his own indexing, but this would turn Alfred into a big fat bloaty beast... something I'm not willing to allow when using OS X's very mature indexing engine provides perfect file searching for 99.9% of users. Have you tried filtering and navigating through Alfred's file system navigation? If you know the exact location you want, you can actually get to that file extremely quickly, especially if you start with a file filter for folders (one of the built in workflow examples). In your [Norris] case, you would use the file filter to search for e.g. Vacations, then use cmd+down to enter file system navigation, start typing "Paris", press enter to select the folder when you see it, then start typing 'sitting'. The file system navigation works like bash, so you can even use wildcards like *in*cafe. Cheers, Andrew

If you setup a workflow and add a hotkey, you can set the "Action" option in the hotkey's configuration to "Show Alfred", so you could indeed have a second hotkey to show Alfred. To make Alfred show quickly with this second hotkey, be sure to click in the hotkey field and set the trigger mode to fastest