FireFingers21

@APS I just whipped this up, is this the kind of thing you're looking for?
 
https://github.com/FireFingers21/alfred-tag-finder
 
Modern versions of macOS seem to make it non-trivial to quickly list every Finder tag, at least from within a simple shell script. My solution for now was to use tag as a required dependency, details in the README.

@APS I just whipped this up, is this the kind of thing you're looking for?
 
https://github.com/FireFingers21/alfred-tag-finder
 
Modern versions of macOS seem to make it non-trivial to quickly list every Finder tag, at least from within a simple shell script. My solution for now was to use tag as a required dependency, details in the README.

@rzagreb Nice! Looking forward to seeing the workflow evolve!
 
Also, I was able to get argv working by modifying the beginning of your script filter code like so:
function run(argv) { ObjC.import('stdlib'); const app = Application('Notes'); const query = argv[0].toLowerCase(); const notes = app.notes.whose({ name: { _contains: query } })();  
I added argv as an argument to the run() function and replaced '{query}' in your variable declaration to argv[0].

Welcome to the forum! Sharing a first workflow is always exciting. Out of curiosity, is the goal of your workflow different from what this other workflow already does?

https://github.com/sballin/alfred-search-notes-app

@TomBenz A lot of workflows use variables created in the Configuration Builder for object keywords. This has the benefit of setting a default keyword while allowing easier user customization; it's all handled from the "Configure Workflow..." menu rather than manually editing each workflow object.
 
In your case, this would let you reuse and programmatically access all the keywords in the workflow since they're stored in variables. If I understand you correctly though, you're not going to be able to use this to dynamically update the Markdown in the "About this workflow" README. In that case, just referencing each keyword as its default value should be easy enough to understand.

@TomBenz A lot of workflows use variables created in the Configuration Builder for object keywords. This has the benefit of setting a default keyword while allowing easier user customization; it's all handled from the "Configure Workflow..." menu rather than manually editing each workflow object.
 
In your case, this would let you reuse and programmatically access all the keywords in the workflow since they're stored in variables. If I understand you correctly though, you're not going to be able to use this to dynamically update the Markdown in the "About this workflow" README. In that case, just referencing each keyword as its default value should be easy enough to understand.

@albertcai101 Welcome to the forum, and awesome workflow! Some suggestions:
You need to list jq as a dependency, as it’s not installed by default in macOS. Without it installed, it’s not immediately obvious why the workflow doesn’t work without reading through the code. The current error checking for the GITHUB_USERNAME and GITHUB_TOKEN fields is unnecessary. Since these variables are set to "Required" in the Configuration Builder, the workflow won't run without them anyway. Checking the curl response instead to ensure the validity of the credentials could be handy though. Consider changing the Keyword argument type to "Argument Optional". This will make the workflow immediately list all repositories without having to type a memorized name first. Consider getting Alfred to filter results, setting the Match mode to either "Any order" or "Sequential". This would make searching much faster since you won't be rerunning the entire script and repeating the same API calls every time you type something new. Lastly, generating XML is fine, but consider going all JSON. You're already using jq, so you can just use that to output to Alfred directly instead of going through the extra steps of converting it all to XML. See my linkding Bookmarks workflow as an example. Looking forward to seeing the workflow evolve, it already has great utility!

@albertcai101 Welcome to the forum, and awesome workflow! Some suggestions:
You need to list jq as a dependency, as it’s not installed by default in macOS. Without it installed, it’s not immediately obvious why the workflow doesn’t work without reading through the code. The current error checking for the GITHUB_USERNAME and GITHUB_TOKEN fields is unnecessary. Since these variables are set to "Required" in the Configuration Builder, the workflow won't run without them anyway. Checking the curl response instead to ensure the validity of the credentials could be handy though. Consider changing the Keyword argument type to "Argument Optional". This will make the workflow immediately list all repositories without having to type a memorized name first. Consider getting Alfred to filter results, setting the Match mode to either "Any order" or "Sequential". This would make searching much faster since you won't be rerunning the entire script and repeating the same API calls every time you type something new. Lastly, generating XML is fine, but consider going all JSON. You're already using jq, so you can just use that to output to Alfred directly instead of going through the extra steps of converting it all to XML. See my linkding Bookmarks workflow as an example. Looking forward to seeing the workflow evolve, it already has great utility!

@Freda The 3.12 update of Notion for Mac released earlier this month is the cause of the change you're seeing. From the What's New page under v3.12.0:
 
 
Make sure the app is updated to the latest version though, as v3.12.1 released a day later fixing an issue with that new feature.

@maestropotvin Welcome to the forum!
 
To answer your first question, Alfred supports hotkey triggers, but not individual key triggers. For that, a lot of Alfred users use a tool like Karabiner-Elements.
 
For your second question, there is an official guide for migrating from Alfred 2 or 3 to Alfred 4. This combined with the guide you've already read should help get you updated smoothly:
https://www.alfredapp.com/help/getting-started/migration/v4/

@Belfong The problem is already solvable with Sean Ballinger's workflow, there's currently no reason for the Alfred team to reinvent the solution:
https://github.com/sballin/alfred-search-notes-app

@FireFingers21 As a side note: For this particular scenario, I configured a hotkey specifically for Finder: ⇧⌘↓. Check if the selection is a file or folder, and on success, route the file path into the "Action in Alfred" object that jumps to "Open with...". It's such a simple but effective little quality-of-life improvement.
 

Super cool, I look forward to trying it out!
 
I'm also with vitor, double thumbs up on the name and icon.

Super cool, I look forward to trying it out!
 
I'm also with vitor, double thumbs up on the name and icon.

While @Stephen_C helps you troubleshoot, I would also like to point out if you still have access to Alfred on your old Mac, your Alfred preferences can be moved/synced across devices. In Alfred Preferences → Advanced, under the Syncing section, you should be able to find where your preferences file is located and likewise set the preferences folder to point to that file after moving it to your new Mac. Could save a lot of headache setting everything up again.

For what it's worth I have Folders as part of Alfred's default results and:
find it incredibly useful simply to type a folder name and press ⏎ to open that folder; don't find it has any material adverse effect on Alfred's performance on my M2 Mac. As for "somehow” adding it's easy. Just do as advised in the link @FireFingers21 provided: go to Alfred Preferences → Features → Default Results and under Extras: check Folders.
 
Stephen
 
Stephen

Being my first time using the language, rewriting in Swift was more of a personal challenge rather than finding the best way to reduce dependencies. I'll definitely keep JavaScript for Automation in mind as a future option though.
 
 
That's good to know, I agree the Dependencies Manager is really good. The Gallery does wonders, so at this point I just have to justify this project being at least as good as jq in this case. If not, I'll continue using the Swift version myself anyway. And since all it does is remap JSON structures, maintaining both would be trivial.
 
I'll test on a clean install of macOS to see which user experience between Swift and jq seems better. As the developer, I really like the Swift implementation. But as far as publicly sharing the workflow goes, I'll see which one is better suited for a wider audience.
 
Thanks @vitor and @zeitlings for your help!

Yeah, that's also what I'm usually doing. Though, I usually don't mind blocking the thread for a moment to compile. Neat idea though!
 
if [[ "$(which swiftc)" =~ "not" ]]; then swift ./main.swift "${args[@]}" # crawl else [[ -f ./binary ]] || $(swiftc -O ./main.swift -o ./binary) # compile ./binary "${args[@]}" fi  
However, I was wondering if the which command is localized, but so far I haven't heard any complaints 😄

For what it’s worth, I tested in Sequoia Beta 4 and the old right-click → Open behaviour worked fine, so I’m not convinced that wasn’t a bug.
 
 
I applaud the desire to reduce dependencies to zero, but remember the Dependencies Manager helps with that. I can count on half a hand the number of times I remember someone not being able to work with that, and even then it was because they completely skipped reading the note at the top of the Gallery page.
 
If the user doesn’t have the Xcode Command-Line Developer Tools installed, this behaviour to compile will pop that dialog, so it’s not completely transparent. The Dependencies Manager also does that, but it guides and verifies the steps along the way.

It’s worth noting you don’t need to use a compiled language to replace the whole of jq. JavaScript for Automation can handle JSON just fine (it is JavaScript, after all) and has an Objective-C to access macOS APIs. Furthermore, Swift is available as a language in Run Scripts, but that may not be viable for this specific use case.

In sum, for this particular case I’m not sure I’d go with a bespoke Swift tool, but I do see the sense in the approach. Compiling is fine, as the user can still inspect the original code. What would not be acceptable is shipping the unsigned binary within the workflow and then trying to bypass Gatekeeper on that (which you’re not doing, so this is purely informational).
 
See @zeitlings’s workflows too, as a few of them use a similar technique to what you’re proposing.

Why is it staring into my soul?

Why is it staring into my soul?

One neat way to do that is check the file’s modification date. That way you don’t need to keep track of a different file or variable, the information is in the file itself. You can touch it to force update the timestamp when needed.
 
 
You can do both. Use AppleScript to update the environment variables and send the same information to the next object in a Utility or as JSON.
 
Note these do not invalidate your points, I’m offering alternatives you may not have considered. I’ll still look into it and discuss internally but it’s important to note AppleScript is itself a slow language and if I recall macOS file system events have been unreliable at times. In general, if you’re changing the workflow itself as you run it, it seems reasonable those changes may not be immediate for performance¹ and stability².
 

 
¹ Imagine never being able to optimise by cache any information and having to read something over and over in the off chance an external process changed something mid run.
 
² Imagine (as way of analogy) running a script and changing parts of it as it runs. Results could be unpredictable.

Gotcha, I too would love a configurable maximum font size for the Large Type, as I don't currently see a way to configure anything more than the font type.
 
@Andrew After a quick search, I found at least half a dozen forum posts, including one from 2013 that you commented in asking for this. In that post, you said the Large Type feature is not going to change, but would a configurable max font size be out of the question? In its current state, sometimes it feels like "Large Type" would be more aptly titled "Gigantic Type", which isn't always ideal.

@gedeyenite You can find your current Desktop Space by looking at the "com.apple.spaces" plist. It's located at "~/Library/Preferences/com.apple.spaces.plist", but you can read it from Terminal or a shell script using the "defaults read com.apple.spaces" command.
 
Each Space has a name/uuid (they're one in the same). There's a "Current Space" field that contains the uuid of the current Space, and a "Space Properties" field that contains the name of all the Spaces currently available. If you can figure out a script that matches the "Current Space" uuid with that of whichever Space your app is in, you should have a good basis for the workflow you're trying to accomplish.

Thanks very much for the response. It was most helpful (as you always are) and set me on the right track.
 
Stephen