deanishe

ARGV is a better model. Apart from being the standard UNIX way to run programs, it's simpler (no language-specific escaping) and faster (no need for Alfred to re-write your script every time it runs it).
 
{query} is still around for backwards compatibility, I guess.
 

You can only delete a Safari bookmark from Safari.
 
There is no API for accessing Safari bookmarks. Any workflows or apps that show them are reading either data Safari exports or Safari's private data. Deleting those is pointless and very dangerous respectively.

Instead of just pressing ↩, you press ⌥↩

Yeah, it's not so difficult to do already. Just somewhat finicky because you'd have to define the snippets in a workflow, not a snippet collection, plus there'd be a fair bit of machinery.
 
If I wanted to use Markdown (or whatever) in snippets today, what I'd probably do is write a workflow that you point at a directory of Markdown (or whatever) files with all snippety metadata defined in the frontmatter (or the filename is the snippet keyword), and it automatically creates the corresponding snippety gubbins in its own info.plist. (That's how Searchio! works.)
 
On the one hand, it's a bit ghetto vs the sort of built-in support we've been discussing. On the other hand, you would be able to manage your snippets in your editor of choice, rather than in Alfred's UI. Also, it's doable today.

This. Your suggestions can be focussed very tightly on your own specific needs, @Chris Messina. The all-important question is how well or poorly a change or feature would work for all Alfred users. Vítor and I give your requests a bit of a hard time because we're measuring them against that bar.
 
 
But what leads you to think what you're suggesting is the 80%, especially when you're implicitly excluding everybody who'd rather use something other than Markdown from the get-go? Why aren't we talking about the ability to run snippets through any processor? The same end result as far as you're concerned, but also useful to people who don't want to do exactly the same thing as you.
 
 
You'd want to put HTML on the clipboard as well (or perhaps instead), imo. That's the "proper" representation of something like Markdown, and some apps (yeah … Firefox) accept pasted HTML, but not rich text.
 
I think the ability to put multiple arbitrary types of data on the clipboard is more interesting in general, tbh. Without even getting into anything semi-complex like rendering Markdown, the ability to put a URL or file:// URL (or even a file list) on the clipboard would be broadly useful. It's a pain to do in code.
 

Well, Script Filters in my case, but that would solve my use case, and setting a variable to the entry point's ID would solve @Aviesh's.
 
More generally, being able to call arbitrary elements by ID instead of having to route control flow through a bunch of Filter or Conditional elements would be helpful. For example, you could show an error message in a Notification from anywhere within the workflow without having to wire everything into the Notification element (though this particular case can also be handled via an External Trigger).

Try /usr/bin/qlmanage -p /path/to/file/to/preview

I think you can also add an alfred:ignore comment to the application if you don't want to delist it from Spotlight completely.

I think this is a poor fit for a workflow, tbh. It’s a hell of a job trying to decipher all the info.plists in your prefs bundle (work out all the Hotkey modifiers etc.) and impossible to navigate Alfred Preferences from a workflow the way ? does.
 
Depends how you look at it, I suppose. As a tool for navigating rapidly to a workflow in Alfred Preferences, ? would benefit from the kind of fuzzy matching Alfred supports for applications in its main search. If it's supposed to be a source of information for help purposes, it would be better served with more and better metadata than looser matching, imo.
 
For example, I tried to find the Hotkey I’d set up to open the current selection in Dropover yesterday. I ended up grepping my prefs bundle because Open URL/File are completely opaque to ? and the only element-specific search terms Alfred recognises for a Hotkey Trigger are “hotkey” and “trigger”.
 
Why can't I find Hotkeys (or Open URL/File) elements based on the applications they're assigned to? Or their notes, seeing as they can't have any other unique text?
 
My personal preference would be to put snippets behind a separate keyword (e.g. ?snip), so they don’t overwhelm other results, and to use much richer metadata for searching. SQLite fulltext search seems a natural fit. Then you can bung absolutely everything in there (notes, workflow descriptions etc.) as long as you assign appropriately low priority.

If it's a short, static list of folders, just create a List Filter by hand.
 
To get a dynamic list, put this script in a Script Filter with “Argument Optional”, Language = “/usr/bin/osascript (JavaScript)” and “Alfred filters results”. Obviously, you’ll need to change targetPath at the top of the script to point to your snippets directory.
 
// Path to snippets directory const targetDir = '~/Desktop'; function getSubdirectories(folder) { let dir = $(folder).stringByStandardizingPath; fm = $.NSFileManager.defaultManager; return ObjC.unwrap(fm.contentsOfDirectoryAtPathError(dir, null)) .filter(name => !name.js.startsWith('.')) .map(name => dir.stringByAppendingPathComponent(name)) .filter(path => { let isdir = Ref(); _ = fm.fileExistsAtPathIsDirectory(path, isdir); return isdir[0]; }); } function run() { let dirs = getSubdirectories(targetDir); console.log(`${dirs.length} folder(s) in ${targetDir}`); let items = dirs.map(path => { return { title: path.lastPathComponent.js, arg: path.js, type: 'file', icon: {path: path.js, type: 'fileicon'}, }}); return JSON.stringify({items: items}, null, 2); }  

It returns a complete path plus a newline, which is not a valid path.
 

I built one for you here. Just add search engines.

It's a bit more complicated than just an Args & Vars: you also need to use the JSON Config utility to get Alfred to insert the query into the URL for you.

URL schemes are poor man's automation used by iOS developers. AppleScript dictionaries is where it's at!
 
Unfortunately, Keychain Access doesn't have one of those either
 
Realistically, I think your best bet is "generic" AppleScript automation to simulate the input:
 
tell application "Keychain Access"
    activate
    delay 0.5 -- wait for app to open/activate
    tell application "System Events"
        keystroke "f" using {command down, option down} -- ensure search bar is focussed
        keystroke "my search terms" -- enter search query
    end tell
end tell
 

Flattery will get you everywhere. Here's your snippet collection for the Wikipedia misspellings (a workflow isn't really appropriate).
 
Do you have a link to the contents of the Microsoft autocorrect list?

It sounds like your "Restore clipboard contents" setting (Alfred Preferences > Features > Snippets > Auto Expansion Options > Tweaking) is too short. Set Alfred to restore the clipboard after a longer delay.

Yeah, but it can't read UTF8 ARGV or environment variables properly. It assumes everything is MacRoman encoding.
 
You can either add some shell scripting to your AS, or use a less awful language.
 
set _decoded to do shell script "echo " & quoted form of (system attribute "SOME_VARIABLE") & " | iconv -f UTF-8-MAC -t MACROMAN"
 

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.

Fakeum

Generate fake test data in Alfred for testing.



Download

Get the workflow from GitHub.


Usage
 
fake [<query>] — List/filter available fake data types ↩, ⌘+C or ⌘+NUM — Copy one fake datum to clipboard ⌘+↩ — Paste fake datum into frontmost app ⇥ — Specify number of datasets to copy to clipboard ⌘+L — Show generated data in Alfred's Large Text window fakeconfig [<query>] — Activate and deactivate locales for fake data ↩ — Toggle selected locale on or off If you specify multiple data, e.g. fake Name 〉 10 for 10 names, the data
will be separated by newlines (\n).

In the case of Paragraph and Address types, the data will be separated
by two newlines (\n\n).

Supported data types and locales

See the GitHub page for details.

It's because Alfred only matches the start of words, and Alfred's rather Western concept of a "word" is a series of characters that come after whitespace (or are at the start of the text).
 
If you're using Safari, you could try my Safari workflow. It uses "fuzzy" search, so it doesn't care about words. Only that the characters you enter appear in the same order in the bookmark's name.
 
I copy-and-pasted your example into Safari, and it worked for me.
 
 
This doesn't only apply to Asian languages. It's an almost inevitable result of developers trying to build an app that works in a language they know nothing about.
 
The more different that language or writing system is to anything they know, the bigger the problems.

+1 from me (to nobody’s surprise).
 
I would definitely love to see some more options for Alfred’s filtering. Fuzzy, OR, AND, and perhaps XOR (which is generally unintuitive, but sometimes useful).
 
Fuzzy search, in particular, allows users to train Alfred to adapt to the way they think/work. The way filtering currently works, I rather have the feeling that I’m learning to adapt my queries to what suits Alfred.

This shell command opens a new Firefox window:
 
/Applications/Firefox.app/Contents/MacOS/firefox-bin --browser  

@GuiB gave some solutions, but didn't explain what the root cause of the problem is.
 
(Excuse me if this explanation comes across as for-idiots or patronising: I'm aiming to explain this just once and link to it in future, so I'm writing this for total noobs.)
 
macOS is basically a UNIX system with Cool Apple Shit layered on top.
 
Alfred itself exists in the Cool Apple Shit layer, but workflows are at the lower UNIX level. This means they must, essentially, be UNIX programs.
 
As such, an External Script element can only run a UNIX executable, which is to say something you can run from a shell.
 
Concretely, that means the execute bit must be set (run chmod +x /path/to/script in a shell), but also that it must be a UNIX program or a script with a shebang.
 
AppleScript, as the name implies, belongs to the higher Cool Apple Shit layer (though AppleScript is pretty damn far from cool), and as a result you can't run it directly via the UNIX subsystem.
 
Fortunately, Apple has written a bunch of programs to access the Cool Apple Shit from the underlying UNIX layer. As @GuiB explained, the one you need to run AppleScript scripts from the UNIX layer is osascript. But there are other super-cool ones, like security, which provides access to the macOS Keychain, and mdfind, which lets you run Spotlight queries from the command line/scripts/workflows.
 
 

Those are two different themes, as far as Alfred is concerned: Alfred doesn't have a concept of theme variants.
 
To set your light theme, choose an Alfred theme when the macOS colour scheme is light. To set your dark theme, choose a theme when macOS is in dark mode.
 
Alfred will remember those choices and switch between them when the OS switches between light and dark modes.

Yeah, those are rather developer instructions, and not very clear if you don't already have a good idea what to do.
 
I've built you a version of the workflow that supports Vivaldi bookmarks. It builds with support for every Chromium-based browser. After you install the workflow, you can delete the ones you don't want.
 
I guess @Jakub Sypiański might like to have the workflow, too.

That isn't where the Spotlight/Alfred data are. You need to specify the directory where the exported metadata are, not the database. I just installed DevonThink 3 demo to test, and the correct path appears to be ~/Library/Metadata/com.devon-technologies.think3 (where ~ means your home directory).
 
Add that to Alfred's Search Scope and see if it works then.