deanishe

I did look to see if there's a forum member of the same name, so I could tell him not to do such a daft thing. But he's not a member… Just in case he googles himself, I'll use this opportunity to say DON'T KEEP YOUR PASSWORDS IN EVERNOTE, FRANKYSEA, YOU PLONKER!

Oof. Keeping your passwords in Evernote doesn't sound like the smartest idea…

Me, too. @phantasm Perhaps you should submit a feature request?

It's an SQLite3 database, as are all .alfdb files. You can open the file with DB Browser for SQLite, amongst other apps.

That's what iTerm does when the connection fails. Are you sure the machine is responsive and the connection details are correct?

As Vero noted above, Alfred Remote gets new features via Alfred, not via updates to Alfred Remote. There hasn't been a new release in 3 years (hasn't been a need for one), so I'd say the chances of an entirely new version appearing any time soon are very, very low.

You're talking about a massive re-write of the application to add a feature that would be broken for a significant number of users/workflows. Why would anyone even consider implementing that?

Did you read my last post?

Well, not just workflows. The way Alfred works is that it expects its preferences bundle to be changed by other applications. It could be Dropbox or Syncthing syncing your preferences, or npm symlinking a Node-based workflow, or a workflow saving/changing its own files. The filesystem is the source of truth, and Alfred monitors that. CloudKit also expects to be the source of truth, and that your app's data will only be manipulated via the app's own CloudKit-aware APIs. Getting Alfred and CloudKit to work together would require completely changing the way Alfred works or writing a custom filesystem–CloudKit sync engine.

There are plenty of faster alternatives. But there's about zero chance of Alfred supporting anything but JSON because JSON is so ubiquitous. OTOH, there are plenty of JSON libraries for Go that are way faster than the built-in one (IIRC, Python's standard JSON library is—or at least was—faster than Go's). Presumably. It's an AppleScript error, after all. I haven't bothered trying to track it down because I hate AppleScript and I don't actually need the workflow. If you're running it via a Hotkey, it would be. You're wasting ~0.2s by saving a variable you don't actually want to save and then another ~0.2s deleting it again later: tell application "Alfred 3" set configuration "JNANA_FILE" to value (quoted form of theFile) in workflow system attribute "alfred_workflow_bundleid" end tell Calling Alfred's set configuration method is not the right way to set a workflow variable, and as I said in the other thread, tell application "..." is slow as hell. This is why I said you need to benchmark code before you start optimising it. If you'd properly benchmarked the workflow's code, you'd know that the workflow is wasting a few tenths of a second with tell application "Alfred 3" calls it shouldn't be making. I'd put money on those two unneeded tell application ... calls taking more time to run than you've saved by rewriting in Go EDIT: Here's the section on setting variables. You've followed the section on saving variables, which is not what you want. If you only need to set one variable via AppleScript, you can return the value and use an Args & Vars to set a variable. If you need more than one, I'd recommend trying to rewrite the script in JXA. It's just as crazy as AppleScript in its own way, but it at least has perfect support for JSON.

Dunno. There just are loads of Latin sayings in English. I guess that one came from a contract or some other legal text?

Yup. When Andrew added List Filters, he had them running buttery smooth filtering fifty thousand items. Alfred is extremely fast. I have no idea why your workflow might be slow. I get the same Expected end of line but found identifier. (-2741) error with both versions The code looks perfectly legit, even if I can't run it. FWIW, you don't need to manually mess around with aw.Cache and json here. There's already an initialised cache at wf.Cache and there's the Cache.StoreJSON method, so that whole function can be reduced to a single call: func cacheLastQuery(queryString string) { if err := wf.Cache.StoreJSON("LastQuery", queryString); err != nil { panic(err) } } Same goes for getLastQuery() mutatis mutandis.

It doesn't. Alfred loads icons lazily after it's already displaying results. Doubtful. What's faster? In any case, Alfred is plenty fast enough unless you're sending many, many thousands of results.

It's a default shortcut that works with pretty much every application.

The section on Saving variables? It does. It automatically puts {query} in the Argument box. If you don't want an argument set, just delete {query} from the box. No. Saving variables takes time. Retrieving them shouldn't take any time unless you're doing something daft like reading info.plist yourself.