Andrew

@Gary King Hmm, I've been playing with this for the past little while and I can actually reproduce this issue, very interesting! I'll take a look at it in the morning. Cheers, Andrew

@Gary King this isn't usual Alfred behaviour - the first place to start when seeing things like this is the troubleshooting guide: https://www.alfredapp.com/help/troubleshooting/indexing/ (specifically no.4, the reindexing). Also, does this happen with the default file search too on your Mac? Cheers, Andrew [moved the original post into the bug forum, and deleted the shadow post]

@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: [LINK REMOVED, Alfred 3.7 pre-release is now available from Alfred's update tab] 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.

It looks like there are issues in the latest Mojave beta with regards to Accessibility access. Apps arbitrarily become unticked in the preferences, or even when listed and ticked, they don't actually have Accessibility access granted in macOS. In the latest Mojave Beta 4, with Alfred at least, it looks like either Alfred 3.app OR Alfred Text Service.app is allowed accessibility access, not both even though they are separate apps. It's a new requirement for an app to have accessibility access to dispatch a key combo (which Alfred and Alfred's workflows do). This is why macOS automatically shows the dialog to add Alfred 3 to the list of accessible apps, and once added, for some reason, this stops Alfred Text Service from having accessibility even though it's still ticked. I'm going to have a think about this. I originally created Alfred Text Service to keep Alfred 3 out of the list of apps needing accessibility, but with Mojave, this may just be complicating things. I may just move the text expansion features into Alfred's core, and then just have Alfred 3 as accessible with no separate text service app. Cheers, Andrew

No.2 is a consequence of Alfred's calculator evaluating the expression. If you disable Alfred's calculator, then === will not change to =0. Both of these have been in Alfred since the early days, so behaviour hasn't recently changed. [moving to help sub-forum]

I've just tested this again and am not experiencing either of the issues above - Text expansion is working, and Alfred Text Service remains in the Accessibility preferences. Having said that, our Mojave test machine is a fresh install so may not be exhibiting macOS bugs which come about by upgrading. Would it be possible to try creating a new user account on your Mac, switching to that user, and seeing if the issue still exists? Cheers, Andrew

@PAUL R FONTENOT Good job Paul - you're learning Alfred fast Just to let you know, all of the objects you see in the built in "All Workflow Objects" workflow are available from right clicking within any workflow canvas. You'll get a popup menu where you can select the items you need such as the "Play Sound", "Delay", "Post Notification" etc. Cheers, Andrew

@deanishe for that to work, you'd need to make the JSON utility pass through {query} as the arg.

@deanishe with the original download, just change the JSON config to: { "alfredworkflow" : { "arg" : "{clipboard}", "config" : { "matchmode" : 0, "matchstring" : "{var:find}", "replacestring" : "{var:replace}" } } } ... and it should work as expected.

@Jasondm007 There are a few things going on here. Firstly, the Replace util should work fine when passing in a JSON configuration (Just tested this, not a bug), but in your workflow, you are passing matchmode as 1 (REGEX) instead of 0 (String), so things won't be processed as you expect. Secondly, @deanishe is correct that there is no actual input query being passed in to process the find and replace on, so you are essentially asking Alfred to do a find and replace of no string at all. If you want to act on whatever is in the clipboard, you could add {clipboard} as the argument in the Arg / Var utility before the Find and Replace. It's also worth noting that when it comes to the find / replace, you don't actually need to configure it with JSON, you can configure it inline like this: Here is your workflow (simplified) which does the find and replace based on your given arguments for the current contents of the clipboard: https://www.dropbox.com/s/mxxkiggrqa8gy1o/Text - Find %26 Replace.alfredworkflow?dl=0 Cheers, Andrew

@deanishe this totally sounds like a bug. I'm gonna move this to the bug forum and investigate!