Andrew

@sepulchra there is actually a little bug in the internal ? search where missing data in a workflow can cause the workflow portion of the search to stop working. This will be fixed in the next Alfred build. For now, do you have the Movie and TV Show Search workflow installed? If so, either delete it, or open it in the Workflow Editor, select the [x] button and hit Save. This is one workflow we know is missing underlying config data.

Investigating this deeper, it looks like a change (bug fix) Apple have made to the NSDateFormatter to prevent line wrapping for the time by using a non-breaking space. Here is a link of others noticing the change: https://developer.apple.com/forums/thread/731850 The workaround would be to use a simple custom date format in your snippet with a normal space/ {time:HH:mm:ss a} Let me know how you get on. Cheers, Andrew

@Steve Ball The clipboard merge already takes into account both the timing, and focused app. In the case of iTerm, if you select some text (iTerm automatically copies), then you immediately ⌘C, then this is two fast (<0.5s) sequential copies to the clipboard, both with iTerm focused, which Alfred interprets as a "clipboard merge". Note that Alfred isn't using macOS events for this, simply looking at the macOS clipboard counter and the focused app. Alfred doesn't differentiate *how* the item was copied to the clipboard.

This is the exact behaviour of the ⌘Space conflict.

@Travis Schmeisser could you type ?diagnostics into Alfred and email the exported file to our info@ address? When you say preferences are not updating, what do you mean? They aren't updating inside the preferences package, or Alfred isn't functioning properly?

@Travis Schmeisser Are preferences saving ok? It's normal for the Alfred.alfredpreferences package (folder) to not update when the contents are updated.

@Steve Ball iTerm will copy the selection to the clipboard automatically (without using ⌘C). If you're subsequently using ⌘C, you're going to be triggering Alfred's clipboard merge function. You have 2 options: 1. Disable automatic copy to clipboard on selection in iTerm 2. Disable clipboard merging in Alfred Let me know how you get on Cheers, Andrew [moving to Discussion and Help]

Note that the input field hanging is almost entirely due to multiple things trying to use ⌘Space at the same time. If you need to use ⌘Space for your hotkey, there is more than just Spotlight using this combo. Take a look at this page: https://www.alfredapp.com/help/troubleshooting/cmd-space/ If you continue to experience this issue, please set Spotlight back to the default ⌘Space, and use ⌥Space for Alfred. Let me know if this doesn't help, and we can explore other avenues. Cheers, Andrew [moving to Discussion and Help]

@Gil C Alfred passes a URL to macOS, and this is passed by macOS to your default browser. What happens after Alfred requests a URL to open is outside of his control. Testing in Safari on Sonoma, the URL is correctly opened in the last focused browser window (private or normal). If this is a recent behaviour change in Chrome, you may be best reporting this to Google as it could either be a deliberate change by them, or a bug. Cheers, Andrew

@Jacob Graf The folder set as scope will always be found as Alfred internally returns this result manually (the macOS metadata query doesn't only returns results inside the scope folders), which is why you're seeing e.g. code t return ~/Test Folder. Just to double check - did you reindex including deleting the .Spotlight-V100 folder as Vero suggested?

@Jacob Graf If you set it to a different folder in your home folder such as ~/Downloads, does it work then? If not, if you create a new folder in your home folder, add in some files, set it to that folder, does it work? It could be something whacky like a some index corruption or a filesystem node is borked where ~/Sites isn't _actually_ in that location, so setting the scope to that folder is breaking. I'm trying to ascertain if other folders work.

@Jacob Graf Your workflow is working as expected for me. To try narrowing down which aspect of indexing isn't working by fettling with your File Filter to see if you can ascertain behaviour changes. For example, try first removing the public.folder from the types, and see if it finds any file types in ~/Sites. If not, try changing the scope to / instead of ~/Sites and adding back public.folder, then seeing if any folders are found. Let me know how you get on. Cheers, Andrew

@renforter Could you provide some screenshots so I can see what you're trying to type, what's shown in Alfred, and let me know what you're expecting to see for the given screenshots? Also a screenshot of Alfred's Features > Dictionary prefs would help. As this is working normally here, the more info you provide, the easier we can work out what's happening on your Mac. Cheers, Andrew

@melhopkop Can I confirm that Alfred has Full Disk Access in the macOS Permissions? (shortcut to get to this from Alfred's Preferences > General > Request Permissions > Open macOS Full Disk Access preferences). If Alfred 5 is already listed here, try quitting Alfred, removing (not disabling) Alfred 5 from full disk permissions, then re-adding him back again, then restarting Alfred. If search is still not working in this specific folder, this will be a straight up macOS indexing issue (corruption?) manifesting itself within Alfred. There are fixes for this... 1. Try renaming the folder to something else, waiting 30 seconds, searching for the new name. If it's found rename it back again. Likewise, try renaming a file or folder within this folder, wait 30 seconds, and see if it's found. 2. A more nuclear option (backup first) is remove this folder from Dropbox by moving it to your home folder. Wait a minute or two, and then copy it back in. If it's a large folder, give it plenty of time to sync back to Dropbox. 3. If these two fail, then reindexing your mac by following the guide here will help: https://www.alfredapp.com/help/troubleshooting/indexing/ Cheers, Andrew

The keyword option only relates to the use of the List Filter in Alfred's default results. In this respect, the keyword's argument options relate to the typed argument after the keyword, which ultimately filters the list items. I have a number of my own workflows which use the "Argument Required" option, and we have seen countless perfect uses of all 3 unique options to create the associated desired behaviour. As such, we won't be recommending people not to use this option, or indeed, removing this option in the future. The behaviour when opening the list filter from an upstream connection (e.g a hotkey, or chaining objects) will always be a search field dedicated to the list filter. If this is the only way you're using the List Filter, you can leave the keyword blank and ignore the keyword's options. Having said all that, you make a fair point that the documentation for this could be improved. Cheers, Andrew

@IndigoHomme There should be zero lag on showing Alfred even on a busy system (and you shouldn't be changing priorities, however you're attempting this). I can max out my M1 Mac across all cores (using Xcode / Analyse) and Alfred is still instant / snappy. Could you type ?diagnostics into Alfred and send the report to our info@ address. There may be a configuration issue causing the lag. Cheers, Andrew

@leongaban Select the "Ignore thousands grouping separator" in Alfred's Prefs > Features > Calculator > Input, then it'll work as expected:

Hi there, I just replied to your email with more details, but for anybody reading this: The number refers to the version of Alfred, so Alfred 3 is Alfred version 3, and Alfred 5 is the current version 5 of Alfred. Cheers, Andrew

@renecum try quitting Alfred on the second Mac (left one in the video) and seeing if the issue still exists. If it does, you have another app running which is watching the clipboard and consuming the data. Data is only consumed via Universal Clipboard when it's requested, and ticking the Ignore options in Alfred prevent's Alfred from requesting the data for the history.

@renecum try configuring both instances of Alfred to ignore the Universal Clipboard data in Alfred's Features > Clipboard History > History prefs:

I'm going to add a defaults write into the next build to extend the latching expiry to (rolling) 3 months instead of 1. A rolling 3 months of not using a latched keyword should be long enough for Alfred to decide it's no longer relevant. A little more info as to why this can't be permanent: Unlike pinning, Alfred continually learns, adapts and latches, which forms part of the magic in Alfred's predictability. As such, the latching cannot grow indefinitely as this data is queried on every keystroke. You can imagine the bloat this could achieve after years of usage. There is currently no timeline for the next build, but from that build onwards, the following terminal commands will extend the latching to 3 months: defaults write com.runningwithcrayons.Alfred-Preferences longlatching 1 defaults read com.runningwithcrayons.Alfred-Preferences Note: this may be removed if we receive any support queries from users which relate to performance and have blindly used this option. This is always the risk in adding this type of defaults write.

It's worth adding that Alfred will automatically infer keeping the window open if you have an input directly followed by another input (i.e. Keyword > List Filter), which is why you don't see the behaviour with the "mygood" keyword. Cheers, Andrew moving to workflow help, as this may help other people too

@Shahar Kedar Nothing has changed between upgrades, and when wanting to keep the Alfred window open, you should have always used this feature. When a window stays open without this feature enabled, it's just incidental (luck)... in the case of seeing the circle on the connection, Alfred will be requesting macOS to hide Alfred after actioning your keyword "mybad", then asking to re-show for the list filter. Depending on timing, and system load, and OS version, the direction of the wind, whether you had a coffee that morning, you may be lucky and macOS re-shows the List filter instead of prioritising the request to close the window. By selecting this option to not hide the Alfred window, things will always work as requested / intended. Cheers, Andrew

@Shahar Kedar double click on the connection circle before the Arg & Vars, and set the option to "Don't close the Alfred window on actioning result". Alfred can infer this behaviour for the "mygood" keyword as it's connected directly into an input, but it's good practice to set the same option for this connection too.

Ah sorry, I misread this, the macOS preview you mean, not Large Type. This is placed wherever macOS deems appropriate, which is likely on the screen with the current window focus (outside of Alfred).