deanishe

I suspect it's so large collections of snippets don't overwhelm other results. In terms of performance, I'm sure Alfred could easily handle full fuzzy search on many tens of thousands of items. 20K is no problem with my Go library, and that's doing much more work than Alfred's matching algos.

In the results. You need to turn on full fuzzy matching to get "nw" to match "Network", like Vero said. I forgot that isn't the default. You can add tags via Finder. In the File > Tags… menu or via Get Info.

Just keep choosing the right application for the keyword, and Alfred will learn to associate them. If a keyword doesn't match an app name at all, add the keyword to the application as a tag.

It sounds like you need to change the bundle ID, too. Absolutely. Just edit the workflows so they all point to the same history file. The proper way to do it would be to add a variable for the path to the history file. Add a variable called, say, history_file set to ~/search-history.txt and change the HISTORY = CACHE / 'history.txt' line to HISTORY = Path(os.environ['history_file']).expanduser() Then you can delete the CACHE lines from the script and don’t need to worry about the bundle ID (delete it). Also, don't forget you can add additional searches to the first workflow instead of creating duplicates.

To add to this, the matching algo is different to Alfred’s main search, too, so I can’t use the same keywords. I’ve trained Alfred to associate Affinity Designer and Photo with affd and affp respectively in its main search. But neither of these queries match the applications inside the Open With action. I think it's very important to have consistent matching behaviour across Alfred's core because keyword–application associations should and do become deeply ingrained.

Sounds perfectly sensible, tbh. "Indexing" is the term we always use, so it would be a good idea to use it in the text of the link to the main page on the topic. Perhaps "Alfred can't find the files I'm searching for (indexing issues)" would be a better link text? Lol @ the detective skills, tho

Unless Vero's changed the site in the last hour, it's literally the first link on the Troubleshooting page:

If Chrome accepts the URL, then you can pass it directly to Chrome by running: #!/bin/zsh /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome 'https://www.youxuan68.com/search.asp?keyword=%u5948%u5B66' But I don't think it will ever work with Open URL because Apple's libraries simply won't accept that URL. Try the following in an Xcode Swift Playground: import Foundation let URLs = [ // test URL "https://www.alfredforum.com", // your invalid URL "https://www.youxuan68.com/search.asp?keyword=%u5948%u5B66", // properly URL-encoded "https://www.youxuan68.com/search.asp?keyword=%25u5948%25u5B66", ] for str in URLs { if URL(string: str) != nil { print(" valid: \(str)") } else { print("invalid: \(str)") } }

It's not judgement, it's fact. %uXXXX escaping is non-standard. Sure, Chrome may support it, but macOS doesn't. The standards are, and they say your URL is not valid. I already told you: fix the URL so it's valid. Chrome may accept it if you paste it directly into the browser, but macOS APIs will not accept your URL. Because it's not valid.

Yeah. That’s because persistFor = 3 doesn’t mean “3 months”, it means “4th option”, i.e. “3 months”. Don't mess with those files unless you know exactly what you're doing.

Alfred is encoding it because that's not a valid URL. You can't get Alfred to open that URL without it encoding the %-signs to make the URL valid, and I don't think macOS will do it either. You need to encode your URLs properly. %uXXXX escaping is not valid.

Try this workflow. Edit the searches.txt file in the workflow to add/remove search engines.

This workflow combines a web search with a history. Edit the Open URL to change the site that's searched (by default, it's DuckDuckGo). You'll need to have Python 3 installed, either via Homebrew or Apple's Developer Tools.

Sorry, no. I don't use Chrome.

File Filters.

Sounds like it's the same problem. Perhaps Apple has changed something in the way Secure Input works?

Nope, afraid not. Chrome doesn't expose an API for manipulating tab groups. Chrome extensions may be able to manipulate tab groups, but there's no way to do it from outside Chrome.

Try the new beta.

How did you do that, if I may ask? Do you have a free developer certificate or a real one?

They rarely are. Menus are designed for people with mice, not scripts. Simulating user interaction is typically a last resort. If you want to automate something, you should always look for an API first.

Try removing the ~ from your exclude patterns. It seems to be joining the excludes to the paths. I should be able to recreate that.

Seems like all the more reason to use a shebang.

Ah, right. That's pretty clever. Dubious, but clever.

I doubt it. What do you need to do? Run the program to get the current profile, then run it again with profile A or B depending on what the current profile's set to. It doesn't get much simpler than that.

Any idea how you got there? Paths from the config file are expanded on load, and everything else (paths returned by find, mdfind, locate) should always be absolute.