luckman212

@vitor Nice little examples! Thank you for sharing those. I like the way you organized the background task into a separate WF object and fork the path to execute them async. Makes it visually easy to understand what's going on.

Here it is. Look at the _spawnSearchJob() function in hn.sh -- hope it is somewhat self explanatory but happy to answer questions. (I am also pretty sure there's probably a better way to solve this)
 
https://github.com/luckman212/alfred-hnsearch
 

@vitor Nice little examples! Thank you for sharing those. I like the way you organized the background task into a separate WF object and fork the path to execute them async. Makes it visually easy to understand what's going on.

Easier way is to use the Custom Argument in the Inbound Configuration and leave it empty.

It's increasingly common for the clipboard to be used to move secrets (like access tokens) between applications, including where one of the applications is the browser. Although Alfred can block clipboard history by application (which is great!), this doesn't help with the browser (because I want clipboard history almost always there). At the same time, various token providers (like Github -  https://github.blog/2021-04-05-behind-githubs-new-authentication-token-formats/, but also Atlassian where I used to work) are adopting "secret scanning friendly" token formats like fixed prefixes.
It would be really useful to be able to configure a list of string prefixes which would prevent that string making it on to clipboard history. Copy/paste would still work, but I wouldn't have to worry about the token finding its way into files I didn't put it in.
Currently I switch off history before doing token manipulations and switch it back on afterwards (and an Alfred level UI for that would be great also - digging through prefs to do it is a bit painful).
I am aware of the `clear` keyword for clipboard history, but by the time that happens, the string has possibly made it into a sqlite database for some time, and automatic backup / sync processes may have moved it elsewhere - being able to control token duplication preventatively rather than curatively seems like a win to me?
Another note - the formats above use checksums for high confidence in systems where false positives are probable (like logs which deal with a lot of data, including data which has people talking about the prefixes 🙂 ) and very expensive (each needing investigation) - I don't think that level of support is needed. If I could just list out the `gh?_` and `ATATT` prefixes, that'd solve my problem.

Glad you like it! And thank you for the suggestions. Few notes on the bottom two:
 
 
You can, by overriding the object’s JSON. Both Thumbnail Navigation and Short Films do that.
 
 
The File Buffer works in Grid View too.

That works now. Set the type key in the JSON to file. Or try it just by sending a list of files to the Grid View with Object Input as the Source.
 
 
Try ⌘0. That shift in size is remembered per object, which means that you can have them bigger or smaller depending on context and also adapt on demand.

The new "Resolve Dependencies" feature is pretty neat and handy! One possible change that would be useful is on this screen:

Instead of just listing the formulae needed, it would be nice for a column called "used by" or "used in" to list the workflow that requires it (if it's used by >1 then just listing the first one would be fine)

This way we could decide if we want to download a large package or potentially just do some housekeeping and remove a workflow that might no longer be useful.

Reading the release notes now, wow a truly massive update! Thank you so much for this! Looking forward to diving in.

Reading the release notes now, wow a truly massive update! Thank you so much for this! Looking forward to diving in.

@luckman212 DING... fresh out the oven: https://www.alfredapp.com/whats-new/

It’s a regular JSON array. Instead of "arg": "one coffee" you do "arg": ["first coffee", "second coffee"]. That will be passed to the next object as multiple arguments.
 
Oh, and good morning!

just wanted to say that Alfred is amazing! super quality build, precisely customizable, and my absolute daily driver for everything. amazing app, thank you!

Ah, that makes sense. Thanks! I wish Alfred would add a feature “only continue if exit code is (not) X."

The new "Resolve Dependencies" feature is pretty neat and handy! One possible change that would be useful is on this screen:

Instead of just listing the formulae needed, it would be nice for a column called "used by" or "used in" to list the workflow that requires it (if it's used by >1 then just listing the first one would be fine)

This way we could decide if we want to download a large package or potentially just do some housekeeping and remove a workflow that might no longer be useful.

The new "Resolve Dependencies" feature is pretty neat and handy! One possible change that would be useful is on this screen:

Instead of just listing the formulae needed, it would be nice for a column called "used by" or "used in" to list the workflow that requires it (if it's used by >1 then just listing the first one would be fine)

This way we could decide if we want to download a large package or potentially just do some housekeeping and remove a workflow that might no longer be useful.

Alfred 4.5 build 1249 macOS 11.5  
When Alfred executes Bash scripts with the standard shebang of `#!/usr/bin/env bash`, it runs a non-login, non-interactive shell (`/bin/bash foo.sh`). This means that ~/.bashrc, ~/.bash_profile, /etc/bashrc etc are not sourced. This makes it difficult to set certain environment parameters, notably $PATH, $HOMEBREW_PREFIX etc.
 
I found that setting $BASH_ENV to ~/.bashrc is a workaround. As per the Bash manpage, that var causes bash to source the specified file on noninteractive shells.
 
TL;DR— is there any way to globally set a variable to apply to all workflows? I can definitely set it for each individual wf, but this would be a nice feature...
 

I sincerely hope someone at Apple is paying attention to these threads. Whoever's in charge (I'm guessing literally nobody...) of making these bad decisions to mess with something as fundamental as text input at this stage of macOS' maturity is really out of touch.

You may already know that you can use {var:} to create user-configurable keywords, which makes workflows more convenient for users. But did you know you can use {const:} to make workflows more convenient for yourself?

Alfred sets a number of alfred_ environment variables with useful information. alfred_workflow_cache and alfred_workflow_data are particularly relevant in scripts but you can access the information in objects too via the {const:} pattern.

It’s common that in workflows which use a main Keyword / Script Filter as the entry point, I’ll have its title and subtitle match the name and description of the workflow. While workflow names seldom change, sometimes descriptions need a little tweak. If you’re copying the information back and forth, you may forget to update relevant workflow objects to match the new wording. Unless, that is, you use {const:alfred_workflow_name} and {const:alfred_workflow_description}, ensuring the information is kept in sync.

When using the plist tweak to disable the caps lock indicator and to revert to the old language switcher in macOS Sonoma, Alfred will not show the text cursor.
 
The plist setting is:
sudo defaults write /Library/Preferences/FeatureFlags/Domain/UIKit.plist redesigned_text_cursor -dict-add Enabled -bool NO as described here: https://stackoverflow.com/a/77296786
 
I am running Alfred 5.1.4 [2195] and macOS Sonoma 14.1 (23B74).

@zeitlings I finally got it. Yes, I see your technique - very clever! Thanks for the tip.

This workflow is staggeringly useful 🏆
I agree with @pontus that Alfred should "bake this in" to his core functionality.

This workflow is staggeringly useful 🏆
I agree with @pontus that Alfred should "bake this in" to his core functionality.

This workflow is staggeringly useful 🏆
I agree with @pontus that Alfred should "bake this in" to his core functionality.

I thought this workflow might be useful to some (for sure it's a small group!) - so posting it here.
 
It copies a "deeplink" to a specific workflow object, which is a link that uses the alfredpreferences:// URI scheme to open the Workflow Editor directly to a specific Workflow, with a specific Object highlighted. This might be useful to developers, or anyone really, for keeping notes or internal documentation about specific Workflows you're working on.
 
See README for details on how to use...
 
Requires Python3 + Alfred 5.1+
 
https://github.com/luckman212/alfred-get-deeplink-to-objec