deanishe

That sounds like an effective if complicated way of going about it… Bear in mind that if you use "Alfred filters results", it only calls your script once, so filtering will be much faster.

That's what happens if you trigger an Alfred Hotkey with "Selection in macOS" set and nothing is selected. Are you trying to create a duplicate Hotkey? If so, try excluding Alfred Preferences in the existing Hotkey's Related Apps tab.

Your script isn't running because it doesn't have a shebang. Also, you can't use setuid on script files, only binaries. Set the script permissions to 755. Anything else is probably a bad idea.

I've made a beta release. It's a universal binary and signed, so I'd appreciate it if anyone with an M1 Mac could test it out. And also generally whether macOS lets it run without complaining.

Thanks for the PR. Rather than having an option to specify where the workflow should go after reload, wouldn't it make more sense to just go back to where it was? I mean, you can run reload from either search or config, so you presumably want to be in that mode. What I think might make sense as an option is what each result "points" to. Currently, each result shows the path to the project file, passes the path to the project file to Universal Actions, and puts nonsense on the clipboard. I'm going to change that to use the (first) project folder for the clipboard and Universal Actions, but I wonder if there's any value in an option to use the project file's path instead. What do you think?

I think it's extremely unlikely that a passing forum member will just happen to know which version of which Messages workflow worked on Mojave back when Alfred 3 was current. You'll probably have much better luck asking in the workflows' own threads, where the only people likely to know that will be notified of your post. Or check the workflows' releases for a version from the appropriate time (2.5 years ago?)

Either you've misread the post or you'll need to explain precisely what you think the issue is. External Script is the preferred way to include scripts in workflows. They work just fine for everybody else. The information in that post is also somewhat out of date because more Alfred elements do now pass multiple arguments (though the user's search query naturally remains a single argument).

Try this instead: ObjC.import('stdlib') ObjC.import('CoreGraphics'); // Move mouse cursor to specified position function moveMouse(x, y) { let pos = $.CGPointMake(x, y); let event = $.CGEventCreateMouseEvent(null, $.kCGEventMouseMoved, pos, $.kCGMouseButtonLeft); $.CGEventPost($.kCGHIDEventTap, event); } // Run script function run() { let appName = Application('System Events').processes.whose({frontmost: {'=': true}})[0].name(); console.log(`frontmost application = ${appName}`); let app = Application(appName); app.includeStandardAdditions = true; let win = app.windows[0], bounds = win.properties().bounds; // Calculate centre of window let x = Math.trunc(bounds.x + (bounds.width / 2)), y = Math.trunc(bounds.y + (bounds.height / 2)); console.log('centre = ' + x + 'x' + y); moveMouse(x, y); } I think it’s a massive bug in the original. I was using Application.currentApplication(), which will be the application running the script, not the frontmost application. I suspect that it works for Vítor and me because we’re running the script in Script Editor, which has windows, and is both the frontmost app and the app running the script. It won't work in Alfred because it will look for Alfred's window (not the active application's), which is probably not visible.

Try this script. It uses the real APIs, not System Events, so it's much faster. Neither does Alfred. If you turn on “Alfred filters results” in your Script Filter, you’ll get basically the same behaviour as Alfred’s built-in quit command. You might also be interested in the workflow I linked above as a starting point. It current only provides an option to quit apps, but it provides a way to specify groups of apps (e.g. "Games", "Not Games") and uses Alfred's File Buffer to save the apps to quit. In theory, you could just add File Actions for the other actions you want to perform (activate, hide, etc.).

In that case, it might be a permissions problem. Or Apple has changed something since Catalina.

And what happens when you open links from other applications? Same thing? What about if you run open https://www.example.com in a shell? Same problem? Does the problem persist after a reboot? Alfred uses the standard macOS APIs for opening links. It doesn't talk to your browser directly, so it's unlikely that Alfred is causing the browser misbehaviour.

You need to give us some information to work with. What does the debugger say?

It probably shouldn't do that. Alfred stores its clipboard history in an SQLite database. As such, you can use wildcards (e.g. *oat matches “coat”, “boat” etc.), but regular expressions are out of the question, I’m sure. I can’t possibly imagine Andrew would consider pulling every row out of the DB to compare them to a regex.

Which application isn't it working with?

Then tell us what the actual problem is, instead of insisting on a specific solution. All your particular wishes can be met by exporting your browser bookmarks to .webloc files and telling Alfred to include .weblocs and the directory they're in its default results. There's absolutely no need to try and force a rejected feature request back onto the table. It is. But how is asking the Alfred team to do it for you when they've already said "no" a dozen times the right approach? Where does Edge keep its data in ~/Library/Application Support?

Possibly. What does the debugger say?

Here's a command-line program for changing display profiles.

That's a handy trick for quickly checking if Secure Input is the problem. The reason for it is presumably the same reason snippets don't work: the subsystem responsible for showing the accented characters can't monitor your keystrokes when Secure Input is enabled.

Vero was unmistakably clear that it's because hardly anybody uses Edge on macOS, and that hasn't changed. What exactly is so terrible about having to use a workflow to search your Edge bookmarks?

Quit everything that doesn't need to be running. One of your other applications has a bug and is failing to disable Secure Entry. You need to identify the buggy app and do something about it because snippet expanders like Alfred can't work if Secure Entry is on. This is not a bug in Alfred, and it can't be fixed from Alfred's side. Only the app that turned on Secure Entry can turn it off again.

Can confirm. I tried it out, and it made a complete mess of my Alfred preferences. Like you say, it unset the executable bit on all the scripts, but the weird thing is, it changed all the perms from 755 to 655, leaving the files executable for everyone but me. Loads of duplicates, too. Took me ages to fix all the stuff it broke.

Messing with the clipboard on exit definitely is something MS Office does. The apps have a feature to purge the clipboard if there's a lot of Office data still on it.

It looks like the Anki workflow has an External Trigger you can call to add a card, which is ideal. You'll have to edit the Linguee workflow to format its output in a way acceptable to the Anki workflow, and to wire them up. If you know Go, you could build a custom version of the binary, otherwise you could write a wrapper script that tweaks the JSON returned by the current binary. That should be doable. I can't test it out myself because I don't have Anki and an online Anki account.

I think @rab523 means they don't want to have to press return to see the search results from the workflow.

Very few. Alfred is designed to do as little as possible when you're not actively using it. It uses the system metadata index (same as Spotlight), so it doesn't need to monitor the filesystem for changes. Obviously, turning on features like automatic snippet expansion or the clipboard history require Alfred to do a bit more. Similarly, the workflow model is designed to run a workflow only when needed, and a workflow should run for as little time as possible. Nevertheless, some workflows do quite a lot of work relative to others and/or may be written in much slower languages, so your mileage will vary there. In any case, you'll never see Alfred anywhere near the top of your CPU processes list unless it's open and actively searching.