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  

This abbreviation is now in the 4.6.3 b1282 pre-release.

I will be making a few tweaks in the next release.
 
The config for Run Script / Script Filter now does a check to see if the language is available and adds a [not installed] on the language selection for missing bins. I have also added a comment to the example Python script (when selecting the Python language) which highlights the impending issue.
 

I do see the value in shortening the prefix of certain paths, especially now that macOS 12 is pushing cloud drive solutions into the ~/Library/CloudDrive/... folder.
 
For now, I'm going to abbreviate this path to ☁️/... and I'll consider a more thorough solution in the future.
 
Cheers,
Andrew

I do see the value in shortening the prefix of certain paths, especially now that macOS 12 is pushing cloud drive solutions into the ~/Library/CloudDrive/... folder.
 
For now, I'm going to abbreviate this path to ☁️/... and I'll consider a more thorough solution in the future.
 
Cheers,
Andrew

{cursor} placement is now in the Alfred 3.2 pre-release.
 
Note that this is done with simulated keypresses, so placing {cursor} at the beginning of a giant snippet can take a little while to reposition the cursor.

One further thing to try is unchecking the option to include "Folders in Home" in Alfred's Features > Default Results > Search Scope, then specifically drag your home folder in (which will add ~). Then delete some of the additional items in there to make your search scope look like this:
 

 
This will cause the underlying macOS Metadata service to craft a slightly different query over the data which may give you results.
 
If you're having problems, and the other solutions above haven't helped, let me know if you try this and it helps.
 
Cheers,
Andrew

This is now in 4.6.2 b1276 pre-release. You may need to reset the eject exclusion list if you've already edited it.

The behaviour has now been rectified in the 4.6.2 b1276 pre-release, so you shouldn't see odd situations where you can't set a combo used in a disabled workflow.

I'm likely going to be moving to a different macOS framework for discovering and presenting ejectable drives in the future, however, I do agree that these backup volumes shouldn't be shown for now.
 
Alfred uses NSString isLike: for this comparison, which allows NSPredicate style formatting (cut down REGEX). I could limit this catching the wrong items by using something a bit janky like this in the default ignore list:
 
[0-9]*-[0-9]*-[0-9]*-*.backup  

@unlink Monterey has some indexing issues which can cause issues for Alfred's file search, especially the earlier 12.0.1 version you're on.
 
As a workaround, try changing Alfred's default search scope to everything. Open Alfred's Preferences to the Features > Default Results, and untick macOS Applications Folder and Folders in Home. Then remove all folders listed, and add in your Macintosh HD. Your prefs will look like this:
 

Now try searching for files using Alfred's file search mode. Show Alfred, press the spacebar, then type a filename. For example:
 
[spacebar]desktop  
For a proper fix on Monterey, refer to @Vero's post here, taking particular note of giving Terminal access to delete the .Spotlight-V100 folder:
 
 
[Moving this to Discussion and Help]
 
Cheers,
Andrew

Thanks for spotting this Chris, taking a quick look at the code, I can see why this is happening. I'll look at fixing this for the next release  
 
Cheers,
Andrew

@vfade you need to use yyyy for the year placeholder, as YYYY is for Year in "Week of Year" based calendars.
 
http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns

@alfreder2 This is usually down to a hotkey conflict, take a look at the usual culprits for cmd+space here:
 
https://www.alfredapp.com/help/troubleshooting/cmd-space/
 
Ensure all 3 points on this page have cmd+space disabled.

I've managed to reproduce it and can see what is happening under the hood, and can see why this has led to confusing behaviour.
 
We have quite a high support load at the moment with people upgrading to Monterey, so I can't promise an imminent fix, but I'll try to get it sorted for the next pre-release.

I'm moving this to closed as this isn't a "conflict", it's just a highlight to show you that there is another workflow using that combo. This doesn't stop the hotkey from working, and seeing that the combo is shared with a disabled workflow is still useful as this notifies of any potential future "conflict".
 
I've added more details in your other thread.

There is no need to do lower level searching like this, simply right click on the hotkey object and it'll show you the shared hotkey combos:
 

 
The feature to enable shared hotkey combinations was added in Alfred 4.1, and the orange highlight you're seeing isn't a conflict, it's just to make you aware that another hotkey shares the same combination. The hotkey will still work, and there is internal logic to ensure the correct one is "run". Here is an extract from the change log which explains shared hotkeys:
 
Hotkey Trigger
The same hotkey combination can now be shared across multiple triggers matching different conditions Added navigation to related hotkeys on the contextual popup menu for a hotkey trigger in the workflow editor Prioritisation of shared hotkey to run, with the following priority: In Focus match takes highest priority, e.g. Hotkey only when Safari in focus Not in Focus takes secondary priority, e.g. Hotkey only when Spotify not in focus Falls back to hotkey with no app specific focus configured Hints shown in orange if a shared hotkey combination is in use Hotkey Trigger object key combo background changes Subtext under the hotkey field updates with warning Show subtle grey background behind application icons on Hotkey Object in workflow editor where hotkey focus mode is set to "don't have focus" Copy and Paste of object (or object configuration) now also retains the hotkey combo Note that this will naturally create a conflict which you will have to manually resolve I see that you've raised a bug disagreeing with the fact that you shouldn't be notified when a hotkey in a disabled workflow shares the same combination. I left this orange highlight in by design, as a shared combo is still a shared combo whether the workflow. is disabled or not. It's still extremely valuable to see that a combo is used in another workflow, even if it's disabled. This avoids a situation later on when the workflow is re-enabled and the user has no idea the hotkey was previously set to a shared combo.
 
Just to iterate, shared hotkey combos aren't conflicts, they were a specifically added feature, and extremely useful when paired with the Related Apps option of the hotkey. The orange is just to highlight that you're using the feature.
 
Do you still feel like there is a bug?
 
Cheers,
Andrew

There is no need to do lower level searching like this, simply right click on the hotkey object and it'll show you the shared hotkey combos:
 

 
The feature to enable shared hotkey combinations was added in Alfred 4.1, and the orange highlight you're seeing isn't a conflict, it's just to make you aware that another hotkey shares the same combination. The hotkey will still work, and there is internal logic to ensure the correct one is "run". Here is an extract from the change log which explains shared hotkeys:
 
Hotkey Trigger
The same hotkey combination can now be shared across multiple triggers matching different conditions Added navigation to related hotkeys on the contextual popup menu for a hotkey trigger in the workflow editor Prioritisation of shared hotkey to run, with the following priority: In Focus match takes highest priority, e.g. Hotkey only when Safari in focus Not in Focus takes secondary priority, e.g. Hotkey only when Spotify not in focus Falls back to hotkey with no app specific focus configured Hints shown in orange if a shared hotkey combination is in use Hotkey Trigger object key combo background changes Subtext under the hotkey field updates with warning Show subtle grey background behind application icons on Hotkey Object in workflow editor where hotkey focus mode is set to "don't have focus" Copy and Paste of object (or object configuration) now also retains the hotkey combo Note that this will naturally create a conflict which you will have to manually resolve I see that you've raised a bug disagreeing with the fact that you shouldn't be notified when a hotkey in a disabled workflow shares the same combination. I left this orange highlight in by design, as a shared combo is still a shared combo whether the workflow. is disabled or not. It's still extremely valuable to see that a combo is used in another workflow, even if it's disabled. This avoids a situation later on when the workflow is re-enabled and the user has no idea the hotkey was previously set to a shared combo.
 
Just to iterate, shared hotkey combos aren't conflicts, they were a specifically added feature, and extremely useful when paired with the Related Apps option of the hotkey. The orange is just to highlight that you're using the feature.
 
Do you still feel like there is a bug?
 
Cheers,
Andrew

This should now be fixed in b1271 pre-release 

Also don't forget to type "reload" into Alfred after moving the folder to Spotlight ignore.
 
Note that if you select "Folders in Home" in Alfred's default search scope, the actual ~/Applications folder will always be shown for relevant search results in Alfred, but if you always select the /Applications folder, Alfred will learn to prioritise this one.

So it seems that the underlying metadata server doesn't like the trailing -. In fact, Spotlight on Big Sur also doesn't match with the trailing -.
 
It looks like this behaviour, previously working in Mojave, seems to have been rectified in Monterey so I'm going to close this issue as I don't want to put in temporary workarounds.

So it seems that the underlying metadata server doesn't like the trailing -. In fact, Spotlight on Big Sur also doesn't match with the trailing -.
 
It looks like this behaviour, previously working in Mojave, seems to have been rectified in Monterey so I'm going to close this issue as I don't want to put in temporary workarounds.

@GatorMapi If you're getting the alert sound (It's actually the macOS "Pluck" sound if you're using Big Sur), then something is happening - either Alfred is doing the merge, or another app (or system thing) is preventing the merge.
 
Just to make sure the fast append is what you expect it to be, can you let me know what steps you're taking to try and merge, and what you're seeing in the clipboard history?
 
For example, if I select "history" on this page and type ⌘C, then select "accounts" and use ⌘C ⌘C, I have see "history accounts" in my clipboard.

@Beery In this case, Alfred will be adhering to the macOS standard key delay before a key repeat. If you set the "Delay Until Repeat" in the macOS System Preferences > Keyboard preferences to the "Long" end of the scale, this will no longer be triggering repeat keys.
 

 
Cheers,
Andrew
 
[moving to help sub-forum]

@Jono this isn't possible, but I'll keep it in mind for if Alfred's theming gets a future overhaul