Andrew

@peppy-blue-wolf I'm currently looking into a workaround to this issue, follow this thread for updates:

@alexbet Quit Alfred and delete the folder you listed (/.../Caches/Metadata/1Password/), then restart Alfred and he will look elsewhere for the data. If Alfred can't find any other locations, this could be the correct folder location, just bad permissions on that folder meaning 1Password can't change the files.

@alexbet that looks like the correct locaton. To double check that Alfred is looking at the correct location, with Alfred's preferences quit, disable 1Password 3rd party integration within 1Password's Advanced prefs, then launch Alfred's Preferences to Features > 1Password. The list should now be empty with a little red error at the bottom. If so, re-enable 3rd party integration in 1Password, then re-launch Alfred's Preferences and they should be back. Let me know how you get on with that, then we can take if from there.

@Kris Alfred simply performs queries on the macOS Metadata, and at no point modifies the configuration, so what you describe is purely coincidental. Having said that, our file search troubleshooting guide will still be relevant for you, as this guide covers fixing the underlying macOS Metadata. https://www.alfredapp.com/help/troubleshooting/indexing/ In your case, step 3 and 4 are most relevant. Cheers, Andrew

@alexbet Do you have the Mac App Store version of 1Password, or direct from website version? What path has been found for 1Password data in Alfred for Alfred Preferences > Features > 1Password > Advanced.

@ihavenoidea Alfred's clipboard history manager watches for changes in the macOS pasteboard, and as such, doesn't even know when you are selecting text. I know that certain apps (such as iTerm) have options to automatically copy text to the clipboard on selection, and there may be other apps which do this too. Cheers, Andrew

@40-02 how odd, would it be possible to email the crash logs from Console.app > User Reports to our bugs@ address for me to take a look? Cheers, Andrew

This is because the item is missing the UID, so Alfred doesn't know it's the same item. If you set a UID, then Alfred will keep the selection: cat << EOB { "rerun": 1, "items": [{ "title": "$(date)", "uid": "date-uid-1234" }] } EOB

@Cappyboppy While navigating in both Alfred's File System Navigating, and Action, you can use the tab key to auto-complete the currently typed path. Cheers, Andrew

@BigLaser Alt may not be the issue, the combination of Alt + up may be reserved or consumed by Synergy. Have you tried switching the Features > File Search > Buffer > Compatibility to using shift+alt in place of alt? This may work around the issue.

@sballin as far as I'm aware, it's not possible to get around this in Alfred 3 by external means. I believe it's actually a bug in Catalina not correctly correlating the home folder through the official APIs, Alfred 4 has some logic to work around this issue.

@BigLaser Alfred isn't doing anything special to interpret the key combos for using the buffer, so there isn't anything which can be "fixed" per-se in Alfred. Have you reached out to Synergy to ask them if there is any configuration you can change to allow the key combos to work? Cheers, Andrew

@(^_^) You can use shift+cmd+, If you need a reminder of what this is in the future, you can hover over the cog and you'll get a tooltip with the shortcut cheers, Andrew

@NoSpHieL What exact version of macOS Catalina and Alfred do you have installed? Do you have the Alfred Classic theme selected? Cheers, Andrew

@Terminal Alfred will either show on the default screen, or the mouse screen. You can change this option in Features > Large Type. Cheers, Andrew

@romebot In the past, when Apple restricted access to their other apps (Contacts, Calendars, Reminders), they added used-defined access in the macOS Preferences > Security & Privacy > Privacy area, so there is a chance they will add back support for 3rd party access to Mail in the future. If and when Apple add this, we can update the workflow appropriately to operate as before. Cheers, Andrew

@ylluminate If you're using Catalina, forcing iTunes isn't compatible with Alfred's default actions, but for Remote / Workflows the AppleScript for these actions is pretty simple ( see https://dougscripts.com/itunes/index.php ), so you could just recreate the actions. Alfred's mini player will only support Apple's actual app though.

@deanishe It is globally defined at the moment, but this could change. There are a few places where it doesn't make sense to see fallbacks, but you still see them. Providing a "No Results" option would fix this while not breaking the default results (where multiple matching workflows could be returning results anyway, including the fallbacks).

@Matt V if it's ok, could you pop an email to our info@ address. I can create an Alfred build which will write some stats every time you show Alfred. I'm mostly interested in what NSScreen is doing before plugging the external display, after plugging it and things going wrong, then what happens after things start working again! Thanks for your help Cheers, Andrew

I've yet to be able to reproduce this issue, but I am determined to, so that I can work around the issue. I'm sure this is a bug in Catalina, as we have had reports that it also happens to Spotlight's window. I theorise that macOS Catalina incorrectly caches the screen sizes reported to currently running apps. Alfred is using these screen dimensions to position himself, so as far as he is concerned, he would be showing in the correct place. If and when I can get this reproduced, I can see if there are any hints which will help Alfred know when this state happens and what he can do about it. It would also help me report something to Apple. Cheers, Andrew

For future reference, and Alfred's support, check that Alfred has Automation selected for iTunes in the macOS Prefs > Security & Privacy > Privacy > Automation > Alfred > iTunes. If it's already selected, perhaps try quitting Alfred, then unticking and re-ticking iTunes. Cheers, Andrew

@rewind take a look at the separator options in Alfred's Features > Calculator options. Cheers, Andrew

Talking out loud here for my future reference back to this thread: Unless the user has specifically selected the workflow, the fallbacks are always (uhh mostly) shown at the bottom of the results regardless when the default "intelligently show fallbacks" option is selected. If a user is choosing a workflow directly (e.g. via hotkey, or selecting the keyword in the default results), then the behaviour is more specific, i.e. it only shows fallbacks when there are no results. I'm possibly happy for that latter behaviour to change, as it has led to potentially confusing behaviour.

I actually missed the original feature request, I think this is a pretty reasonable addition to Alfred. There could be 2 options along the lines of "show x result for no results" with no action, and "show workflow error as result" which opens the workflow editor. I'd be happy to hear any further input on this!

I'm open to implementing this. One of the reasons this hasn't been a thing so far is it is much easier for users to accidentally get themselves into a confusing situation. What would you consider to be the desired behaviour if there were a hotkey conflict? (e.g. set same hotkey on two different synced macs in different workflows, which when the sync merges, they are both "valid").