Andrew

@Tsunami thanks for spotting this! If you refresh that page, it should now be fixed Cheers, Andrew

@digital_literacy - @dfay is right, I can see in the second screenshot that you have set a collection prefix of 'asana' in the subtext of the collection. Edit the collection and clear the prefix Cheers, Andrew Moving to discussion and help

@voxel Alfred, by default, doesn't read anything off of your non-primary drives to prevent issues like this from happening. I have even added an option to use file type icons on external drives to prevent things from spinning up unnecessarily (see screenshot). One thing which may be causing this is having the second slower drive within your default search scope. Alfred runs the metadata queries asynchronously, but the callback involves some interactions with the main thread. Some Apple API calls which Apple claim to be non-blocking can, in rare configurations, cause blocking. I haven't heard this to be a problem for quite some time though, perhaps with newer iterations of macOS. What is your default search scope set to? If it includes the drive which spins up, consider moving file search on this drive to a workflow so that the drive only spins up when you are in control of this. It may also be worth reindexing your Mac's metadata which may remove some stale metadata links between the data on both drives (which may fix this). Cheers, Andrew

@mmcduffie Could you clarify what time period you are referring to? Alfred's bookmark feature came about in September 2017 after Apple removed metadata indexing of Safari bookmarks which had Alfred had used since the very start. Alfred now reads the bookmark data directly and caches them internally. At the same time, I took the opportunity to add Google Chrome bookmarks native to Alfred (the first time Chrome bookmarks were accessible within Alfred natively). Alfred should still sort results based on usage. If I type a bookmark and select it once or twice, it's sorted up the top. 1/ Alfred didn't show Chrome bookmarks before this time. Which timeframe are you referring? 2/ Apple always intended the reading list to be your temporary reading queue, so I didn't anticipate this being an issue. I'll take a look to see if reading list items are marked as such and if so, I'll add a ticket to look at making this optional. Cheers, Andrew

@donmc that makes it a bit easier! As this is to do with 1Password data, could you pop an email to our info@ address and I'll let you know how to find out the 1Password UUIDs you need to open your secure note Also include in the email if you're using 1Password 6 or 7. Cheers, Andrew

@davosian using cmd+c on the answer will give you the literal result including the separators. If you just action the result (using return), then this won't include the thousands separator. Cheers, Andrew

@allstrike Alfred needs to be granted automation access for using the terminal action. macOS Mojave should have automatically shown you a popup requesting access when these were needed. Take a look in the macOS preferences under the automation tab, and you should see these two ticked: Also note the comedy Mojave automation icon bug Cheers, Andrew

I've just posted an update with a link to an Alfred 3.7 beta you can try:

I've just posted an update with a link to an Alfred 3.7 beta you can try:

I've just posted an update with a link to an Alfred 3.7 beta you can try:

I've just posted an update with a link to an Alfred 3.7 beta you can try:

I've just posted an update with a link to an Alfred 3.7 beta you can try:

A few things changed in macOS Mojave Beta 4 which has meant a change in the way Alfred will be dealing with macOS Accessibility access and general permissions. In Alfred 3.6.2 and before, Alfred separated the permissions into a helper app called Alfred Text Service, but since Beta 4, it seems like macOS doesn't like two apps within the same package and same signature (Alfred 3 / Alfred Text Service) from sharing accessibility access - This is likely a bug in Mojave. Nevertheless, since Mojave now also requires accessibility permissions to simulate key events (Which Alfred uses quite considerably for clipboard integration, workflows, file actions), it makes sense to now consolidate Alfred Text Service into Alfred's core and make Alfred the only app which requires accessibility access. When you launch Alfred 3.7 for the first time, if you haven't already granted Alfred 3 accessibility access, you'll be shown this dialog: Select "Let's get started..." and tick Alfred 3 to have accessibility access. Alfred will then restart himself and automation / text expansion should work as expected Here is an early beta version of Alfred 3.7: https://www.dropbox.com/s/wju2amrum2nu0n1/Alfred_3.7_926.dmg?dl=0 NOTE: If things still aren't working as expected, quit Alfred then open the macOS Security & Privacy > Accessibility preferences. Remove both Alfred 3 and Alfred Text Service, then restart your Mac. Run Alfred and you should get this dialog above. Let me know how you get on! Cheers, Andrew

@beetlefrosch These are the fallback searches. Take a look at this page for how to change them: https://www.alfredapp.com/help/features/default-results/fallback-searches/ Also, you can change the default search engines to be .de by changing your location to Germany in Alfred's General preferences tab. Cheers, Andrew

@Chris Spiegl no need to reply to all the Mojave threads, they are all the same issue of accessibility access in Mojave Beta 4 which isn't allowing event capture and simulation. I'm looking at working around this in the next day or two (plus reporting the issue to Apple) which should help with all the related issues.