vitor

Start your query with a space (you’ll see a '). It’ll look in your system. Search for the name of the parent and it’ll allow to drill down the path in greater detail.

Something like this, in ruby: require 'time' t = Time.parse(ARGV[0]) puts(t.hour * 3600 + t.min * 60 + t.sec) Here’s a Workflow.

That’s exactly what Alfred does (documentation). Maybe you can record a video of what you’re doing, so your question is clearer.

Welcome, @Art. When making a request or a bug report pertaining to a specific workflow, please do not open a new thread to discuss your issue. Making a new thread, while it seems like it’ll give your problem visibility, will only fragment the discussion and make it less likely the author and users of the workflow (the people that can actually help) will see it. Please read the Reporting Problems with Workflows topic, as it gives a nice overview on how to make a report with a better chance of being addressed. In this case, there’s no way any of us can know which Workflow you’re talking about.

Alfred has a Post Notification object.

I haven’t looked deep into the Workflow, but with your current approach you’re in for a really bad time down the line. Always quote your variables. Never mv $file $1 unless you know how that can break and you want to take advantage of it. Use mv "${file}" "${1}" instead. More importantly, file names can have a truckload of special characters than can be interpreted by the shell. An apostrophe in a file name can send everything to hell, if you’re not careful. Instead, take advantage of the combination of find and xargs (check their man pages). find has -print0 that can output its results separated by an ASCII NUL character. On the other end xargs has -0 that takes such output. If you check their manual pages, you’ll even see both these options exist precisely to be used with each other. They were made for these cases. While you’re at it, check the documentation of find to do what you want. Instead of getting the contents of a directory as a multitude of strings, get the path to the directory itself and pass just that. Then tell find to get everything inside that directory not recursively.

What you’re looking for is called “fuzzy searching”. Alfred does it for applications but not other things, for a reason. Also see the rest of that post, as it’s exactly about that. But there are Workflows for that, such as @deanishe’s Fuzzy Folders.

Missed that. Thank you for the correction. If the license allows. For example, it it’s GPL (possibly the least free of all free licenses, despite their logo) I just write it off completely and look for something else (so I don’t have to make my own code less free). I it’s MIT or BSD, I typically include a _licensed directory at the root of the Workflow and inside keep a directory for each thing I’m sourcing, with their code and license (like so). That allows me to say “everything is public domain (or whatever license you choose), expect for what’s inside _license that have their own licenses”.

It’s not Alfred that doesn’t have it; it’s macOS. If you want Python 3 in macOS (and Alfred), make a bug report. jsawk is just a bash script with no dependencies and a permissive license. Just distribute it in your Workflow’s directory and call it from there (or add the directory to the PATH). That’s the best kind of dependency you could ask for: a single file with no dependencies and a public domain license.

Markdown to BBCode syntax conversion. The conversions it supports (I can add more via request) are: Bold → **example** Italic → *example* Bold and italic → ***example*** Horizontal rule → --- or - - - or * or * * with as many - or as you’d like, as long as they’re at least three Strike through → ~~example~~ Images that send to an external URL → [](link_to_website) Images →  URLs → [description](link_to_website) Quotes → start lines with > and a space Code blocks → triple backticks on one line, write code, triple backticks on another line to end Inline code → with a backtick at the start and another at the end, by default it’ll convert the text to a monospaced font with grey background Differently sized headers → start lines with # or ## or ### or ####, and a space. End them with any number (including none) of spaces and # characters Unordered lists → precede items with + or * or -, and a space Ordered lists → precede items with a number, a period, and a space Footnotes → [^1] (where 1 is any number) anywhere in your text, and again at the end as [^1]: with the footnote’s text Changes that span multiple lines (code blocks and lists) should be preceded and followed by empty lines (except it they’re at the beginning or end of your text, in which case the extra empty line at the top or bottom, respectively, is not needed). All the code is in the script inside the Workflow — it’s one line per substitution and they’re all commented so you shouldn’t have much trouble changing anything you’d like to be handled a different way, even if you don’t understand regular expressions (you’ll mostly need to care about what’s on the right side of the commas). Download | Source

@nikivi Can’t reproduce. That lines works fine here. Make sure you have the latest version and check the debugger.

Get the Searchio! Workflow by @deanishe and connect a Hotkey Trigger to the Google search.

That is not possible with Alfred’s feature set, no. You’ll need to be more specific.

Issue is some Workflows have so many possible inputs, adding an External Trigger for all can become quite a mess. So I typically only add the ones I need or that I think will be particularly useful. If someone else needs another, its easy enough to add and I can even help the user make it custom. You’d need to show me your version working without for me to say for sure if I could use your approach.

File action to rename the selected directory or file (preserving the extension). Use Alfred to pick what you want to rename and choose Rename as the action. Alfred’s main window will appear and you type a new name (don’t include the file extension). Download | Source

Yes. Forgot to mention it in the original post, but they’re all keys that if you press them once, they don’t output the character itself, but a kind of “waiting mode”, waiting for a letter. Like this (notice how it gets an underline): If you type an “invalid” letter or the same diacritic, it gets output → ~e ~~. They sure do.

This is low priority. It’s a minor UI bug that does not prevent functionality. Here’s a Hotkey Trigger I’ve setup with ⌘⇧`: As you can see (or rather, can’t), the ` does not show. However, in practice the keyboard shortcut is recognised and works as intended. Other diacritics such as ~ and ^ have the same behaviour.

Thank you. Glad you find it useful. To trigger it externally, you’ll need to add an External Trigger that connects to the top Run Script. Yes. Admittedly that External Trigger is more like an Internal Trigger. It’s not meant to ever be called from outside the Workflow. I’m using it as a trick to pass a bunch of variables around without having to resort to temporary files.

Call top for an auto-updating list of processes, ordered by CPU usage. Type to filter by process name. On each process: ⌘↩ quits. ⌥↩ forcibly kills. ⌃↩ limits CPU usage. fn↩ lowers priority (increases niceness). ⇧↩ freezes. ↩ gives more granularity over the options. Download | Source

Alfred filters results in Script Filters is a great time saver. However, it’s rather limited as it only filters from the title. Initially I was hoping it would work at least on subtitle as well (i.e. on all visible info). Even better would be to add a new JSON key — filter_info — that would not be shown anywhere but where we could store info that would be used to filter the item, in addition to its title. Another idea would be add a new option to Run Behaviour that’d let us pick what keys to consider when auto-filtering. As an example use case, I would use it on my Pinboard Workflow to allow pages to be filtered by description and tags.

Went back on a previous decision. In practice, getting all tools at once and getting a PATH from that seems like it might be easier to manage and less weird to call in the Workflow itself (call the tool instead of a variable with its path). Starting to add it now to Workflows. We’ll see if it’s better or not.

How it works View a version with syntax highlighting. Call it with the arguments for the tools you need (--help will list all valid ones). It checks if the arguments are valid (i.e. if the script supports those tools). * If it does not, it fails and explains why. * If it does, it continues. For each tool, it checks if we already have it installed (including in /usr/local/bin/). * If we do, it checks if it was previously installed by this script or not. * If yes, check how long since its last update. If longer than a defined period, update it. * If not, leave it alone. * If we do not (have the tool installed), download it to ~/Library/Application Support/Alfred 3/Workflow Data/com.vitorgalvao.alfred._sharedresources. A PATH which includes all tools is output. Use it to set the PATH in your Workflow. Notes I’m using ~/Library/Application Support/Alfred 3/Workflow Data/com.vitorgalvao.alfred._sharedresources (technically, {var:alfred_workflow_data}/com.vitorgalvao.alfred._sharedresources) because I do not yet know if this is a good idea or useful to anyone else. I don’t want to presume and clutter your Workflow data directory with something you have no idea where it came from. So for now it includes my bundle ID, making it recognisable. The leading _ should also help to clarify this is not from a Workflow named SharedResources. I’m sharing the method not only because it might be useful to someone else, but to extend it and gather feedback. I’m starting to use this in my Workflows and everything seems fine. But I’d still like to know if there are no objections to it. To me it sounds like a net win, but I might be missing something. Reasoning Bundling dependencies with Workflows makes for a better experience. It ensures users can start using our Workflows without fumbling with configurations or extra downloads. Many would have a hard time doing so. The tradeoff — a slight increase in size for the workflow — is mostly worth it. For most dependencies, whatever version we bundle at the time will be sufficient. They don’t tend to be updated all the time, and even if they are the version you included shouldn’t break on its own. If you ever need to update it, you do it and release a new version of the Workflow. There’s one notable exception to this rule: youtube-dl. It’s an incredibly popular and capable tool with constant releases. But if you want to include it in your Workflow you need to include a way to auto-update it1. You need this since what makes youtube-dl break are external factors; there’s no other option. A few of my Workflows use youtube-dl. Even though it’s not huge (≈1.5MBs), having a bunch of them with the exact same bundled tool, each one updating it at different times, is inelegant. It was from this use-case that _sharedresources was born. 1. Unless you want to go through the trouble of constantly releasing new Workflow versions.

If it’s fast enough, I’d rather have those extra 5MBs and the better filtering than not.

I’m picturing a single binary (alfred_filter) that’d take two arguments: a string to search and an Alfred-formated JSON, and the tool would return the JSON with only the items that matched. Is that what you had in mind? In addition to my original idea, it could also be an addition to “Run Behaviour” that’d let us pick what keys to consider when auto-filtering.

Troubleshooting File Indexing Issues.