vitor

Yes, it is possible in several ways. For example with a Script Filter or leveraging Fallback Searches. I’ve found several Alfred Workflows for Obsidian (shimmering-obsidian, obsidian-alfred). Have you given those a try?

That’s how it works for me, I use it every day. It’s not a specific setting, that I recall, so something else running on your machine may be preventing the Esc from going through. Alfred also closes with ⌘W or if you use its hotkey again. Do those work for you? Also, what versions of Alfred and macOS are you on?

The Alfred 4.6 Released: Ready for macOS Monterey blog post has the answer: Essentially: Open a terminal. Install Homebrew. Run brew install php.

First time that has ever come up, as far as I recall. Do you have a screenshot? What are your versions of Alfred and macOS? Sounds like my setup. I’ve never seen Alfred take up a lot of RAM or CPU.

@alvint Getting somewhere. See if this version works for you.

No need to apologise, but perhaps help me understand what your steps were when you bumped into the new problem. What do you think stopped you from realising it was the same problem? Was the first explanation not clear enough for your mental model? You mean feedback in the debugger? That’s also easier in Zsh, append >&2 to your command to redirect STDOUT to STDERR: your_command >&2. It does, I understand you’re using what you know. But in this case the alternative is really simple (literally three characters) and superior in every regard. You had already done most of the work!

That’s the same error, with the same cause and same solution. Use the full path to the tool. And be sure to check what I linked you to if you still don’t understand the cause. Your previous code was better. Zsh is ideal for this sequence of steps; switching to node needlessly complicates it and makes it less portable. You’re invoking a shell from your node code anyway, so the switch is all disadvantages.

What about this Workflow, does it work for you?

@Afoan

Make a Run Script Action with default options and write killall 'APP_NAME' 'APP_NAME'. Example: killall 'Brave Browser' 'Safari'.

I’ll rephrase my request: please avoid posting serially. That muddles the discussion for everyone coming after and is annoying for the people who follow the thread, because they are constantly pinged. Today they will have received six emails from your replies, but no more than two were necessary. Remember this is a public forum, not a chat app. The goal is for everyone to be able to benefit from the questions and answers. Impatience makes us miss important information. I don’t have access to you or your machine so I can only take guesses at what you’re doing wrong or what is odd about your setup. To get help, you need to be collected and think with me what about your setup is different from (literally) a few thousand people using this without your problem. Have you checked the debugger? Have you tried :gdrebuildcache?

Again, have you followed the instructions in the previous post? Please try and reply to everything at once so we avoid unnecessary back and forth with the same questions. That muddles the discussion for everyone coming after and is annoying for the people who follow the thread. After you run the command from the previous post, in the same Terminal run ls -lA and post the results.

You don’t hit return to show the result, you do it to complete the keyword. Showing the result happens after that. It’s an important distinction. You can’t, and that’s by design. Imagine if every Script Filter auto-ran with partial keywords: you’d have tons of Workflows running all the time by mistake, cluttering and slowing down your results. You’re asking for things to run before they are called, which is impossible. If you need the Script Filter to trigger sooner, consider shortening its keyword.

Update. When closing the matching browser tab, do it for all windows. Also, improved handling in Safari. To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

That localhost error is not related to the Workflow. Have you followed the instructions in the previous post? What’s the result of: ls -lA "/Users/alvin/Library/Application Support/Alfred/Alfred.alfredpreferences/workflows/user.workflow.A41E4C52-64AF-41DB-8A77-AA42563B3D47"

Welcome @allyalfie, No Workflow needed, you can type quit and will be present with a list of running apps to close.

Update. Rewrote the Workflow in JXA and added quality of life improvements. Now you’ll get feedback when typing the new name, and if the desired target already exists it won’t let you proceed (previously it appended the date to the name). To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

Updates. Removed pngpaste as a dependency to uploading or saving clipboard image data in favour of a custom solution. Saving image data from the clipboard now saves it with the same name pattern as screenshots. To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

Welcome @sebastianp, In order to get submissions, you should post the contents of the Workflow on GitHub as well. That’s how people will be able to make modifications and directly send them to you for review. Quick note: there’s little point in zipping .alfredworkflow files because they are themselves zip files with a modified extension.

Uncertain how that happened (are you using Maestral, per chance?) but that needs fixing. Right-click the Workflow in Alfred’s Preferences and “Open in Terminal”. Then execute the following: chmod +x gd rebuild_cache Then try again.

Welcome @alvint, Please follow the first paragraph of the second post in this thread.

When asking for help with a Workflow, please upload it somewhere as we can’t properly help you without access to it. Debugging can already be hard when looking at the thing, and right now we just have a description. We’re shooting in the dark. See the Reporting Problems with Workflows topic for an overview on building effective reports.

No, with a Script Filter you can have your entry say anything you want. There’s no difference between returning one result or multiple; technically you don’t need your Script Filter to filter anything. It’s the only way to execute code as you type and have it programmatically show up in the results. The exact implementation will depend on your Workflow. Right now we only have a vague description, without seeing it it’s not possible to be more precise.

On the contrary, that is the way I recommend! It’s easier to implement correctly. Note my comment above: “The Hotkey route” is as simple to implement as the File Action route you demonstrated. The AppleScript route is more convoluted (emphasis added): But it is necessary if you want to use a Keyword in this situation and not a Hotkey or File Action. And @ilium007 did really want a Keyword. I gave my opinion on what I consider the most practical way and explained why. But I know people have different preferences, and sometimes you just want to do it the way you want to do it, so I also gave the answer on how to do that. This way the person on the receiving end considers new possibilities but also gets to go with their original plan if they so wish. I find that to be a kind way to help. Even if the original requester only takes value from one of the solutions, someone coming afterwards (you) may benefit from the other. I like sips and use it when it’s enough for my needs, But @ilium007 used magick in the request. Suggesting another tool amidst the other explanation would have made the reply more complex than (what I judged to be) worth it.

It is possible with a Script Filter.