Blake

I can confirm that with Alfred 5.1.1 [2136], the issue is indeed fixed on my end too. Thanks a bunch!

Steps to reproduce: Make sure "Enable Quick File Search mode" is turned on (in Alfred Prefs -> Features -> File Search -> Search). Press the Alfred hotkey to show the Alfred bar and then press Space to enter Quick File Search mode. Enter any search term. Optional: use the arrow keys to navigate to one of the search results. Press Tab to autocomplete the file name of the selected file. Expected result: The full file name appears in the Alfred bar, so you can, for instance, copy it to the clipboard. Actual result: The Alfred bar is cleared and you only see the single quote character that indicates that Quick File Search mode is (still) active. Notes: This regression appeared in Alfred v5.1 (to which I updated only a few days ago). The issue happens reliably on both of my Macs which are both running macOS 12.6.5 (and Alfred v5.1 [2134]) Tab-autocomplete still works in other contexts, for instance when doing a normal search (without pressing Space at the beginning) or when doing a search via the Searchio! workflow.

My guess is, the Agenda workflow sets the wrong type of date for the reminders it creates. Even though invisible in the GUI, Reminders.app actually differentiates between a "remind me date", which is what is set when you manually create a reminder, and a "due date", which is likely what the Agenda workflow sets. Only the "remind me date" generates a notification when it is due. I had exactly the same issue ages ago with a different Alfred workflow. Since that workflow was AppleScript-based, I was able to fix the issue myself (see here). The Agenda workflow seems to use an executable binary to create the actual reminders, though, so it would be much harder to fix this issue without @rknightuk's help.

The workflow recently broke the same way on my Mac: Whenever I try to do a search, I get "Search IMDB for {my query}" together with always the same results, regardless of what search terms I use. If anyone has an idea of how to fix the workflow, I would be very grateful. I've tried the "Movie and TV Show Search" workflow linked above, but for my purposes, the "IMBD Search Suggest" workflow works much better (e.g., it is much faster, and it allows you to search for actor names, too).

I just wanted to encourage you to officially support Amazon Smile searches, deanishe. I love using Searchio for Amazon searches, but 3 out of 4 times I forgot to switch to the Smile version of the product page before placing the order, so for most orders, the charity of my choice did not receive any money, which is not great. It took me a bit to figure out how to manually add Smile support by changing the right json file. I first tried editing "./Alfred.alfredpreferences/workflows/user.workflow.9B99D5C0-6A24-4093-99C6-88AE3F131D9C/lib/searchio/engines/amazon.json", but that did not have any effect. Here is what you need to do to make the Amazon searches for your country yield the smile versions of the product pages (in Searchio v2.0.0-rc1): - Create the Amazon search for your country from within Searchio - Go to ~/Library/Application Support/Alfred 3/Workflow Data/net.deanishe.alfred-searchio/searches/ and open the amazon json file with your country code in a text editor (e.g., BBEdit) - Now change the "www" in the "search_url" parameter to "smile" (so that the whole line looks something like: "search_url": "https://smile.amazon.com/gp/search?ie=UTF8&keywords={query}"), and then save the file I hope this helps others who come to this thread looking for a way to make Searchio do Smile searches. And again, if you could officially support Smile searches, deanishe, that would be awesome, because having to manually edit a json file might be a bit too much for novice users.

Just wanted to confirm that the updated workflow now works with OmniFocus residing in a subfolder of /Applications. Thanks for all the excellent work!

My OmniFocus application was located at /Applications/-other/OmniFocus.app before I moved it to /Applications. I have a bunch of subfolders (e.g., -audio, -graphics, -tools, etc.) in /Applications that I like to use to organize my applications. I have more than 250 applications on my Mac and this system makes it much easier for me to find those applications/tools that I use very infrequently and which names I often don't remember. Maybe the ideal solution would be for the workflow to search for the location of OmniFocus on first launch using the method outlined by deanishe. This location could then be remembered by the workflow and only when loading the icons failed, the location would need to be determined again. If that is too much trouble for what might be a small group of users, just putting a brief notice in the readme file, that the OmniFocus application needs to reside in /Applications, would already help a lot.

The workflow would not show the icons for the items found on my Mac. After some failed troubleshooting attempts I finally realized that the problem was that OmniFocus has to reside directly in /Applications for the icons to load. I prefer to organize my Non-MAS applications in subfolders, which broke that part of the workflow. So if anyone else suffers from missing task icons, move OmniFocus to /Applications. Maybe a note about this in the readme file would be a good idea. Alternatively, the workflow could scan for the location of OmniFocus and adjust the paths accordingly. By the way, I already really liked the workflow before, but now that it is fully working for me, it's absolutely fantastic!

That absolutely helps, thank you for the prompt reply. While I do feel a bit stupid for not seeing that option myself, that feeling is overshadowed by the joy that the issue has already been solved without me knowing about it. Again, thank you for all your great work!

Searchio is a really great workflow, but I wished you could force it to optionally search for the actual phrase you've entered (i.e., directly pass the entered terms to the appropriate search engine web page). Most of the time, the suggested search results are very good, but I also regularly run into situations, where the suggested search terms differ from what I've actually entered. I noticed this especially with the Amazon search (and there especially with model numbers, which you often really don't want to get wrong if you are searching for a specific part), but it also happens to me with other engines such as DuckDuckGo (usually when you search for less common terms). I tried defining Web Searches in Alfred with the same keywords as their counterparts in Searchio, so that I would always have a static "Search with Engine X" option among the results as a fallback. Unfortunately, that did not work very well either: Since I usually use the Searchio results, the Web Search entry is regularly pushed to the end of the list, so that I need to scroll down. Or worse: once in a while, the entry for the Web Search simply does not appear at all among the Searchio results. In the 93% of situations where it works as expected, I'm absolutely thrilled to be able to use such a nice and sophisticated workflow that supports such a large number of search engines in such a convenient way. In 6% of the situations, however, I start to wonder if it would not be easier to just go back to the simple Web Searches that I used before I discovered Searchio. In the remaining 1% of situations, I do things like (unsuccessfully) looking into the Searchio code to see if I can easily make the necessary changes myself, or writing a very long forum post about it. After thinking a bit about this issue, I could imagine two ways how it could be addressed. The first option would be to implement that holding down a modifier key while hitting return would force Searchio to pass the entered search terms verbatim to the appropriate search engine. This would not visibly change how Searcho currently works, and instead just add additional functionality. The second option would be to always include a static search for the entered search term as the first result that Searchio returns. The advantage of this approach would be that it would also address another issue: if you type really fast and hit return immediately afterwards, you often do a search for a pretty incorrect search phrase, because you hit return when the results list is still in the process of being built and sorted. The downside of this option would be that users who encounter neither issue (because they don't type too fast or don't often search for uncommon search terms) would always need to first hit arrow down once to get to the top search suggestion instead of being able to simply hit return. I guess injecting the static Web Search always as the second result could address this downside, if that were feasible. For me personally, the second option would be the preferred solution, but the first option would also be a tremendous improvement. Anyway, thank you very much for your time and attention, and, more importantly, for such a nice piece of software.

I installed DEVONthink Document Search today for the first time and seem to experience the same problem, i.e. I can see my database with "devondb", but "devon search term" does not yield any results. When I run this command in the terminal, I don't get any results (i.e., just the new prompt). Does that indicate that it is a Spotlight indexing issue? Did something maybe change with Yosemite that broke the workflow?

Thanks, David, it works as advertised! Since I used the original workflow with the "Cursor=left" setting (so that I can enter a keyword before the selected text), I modified the bundled AppleScript in the following way: set prev to the clipboard tell application "System Events" to keystroke "c" using command down delay 0.2 set currSel to " " & the clipboard set the clipboard to prev tell application "Alfred 2" to search currSel tell application "System Events" to keystroke key code 123 using command down (this adds a space before the selected text and then simulates cmd-left to jump to the beginning of Alfred's search bar)

After having thought a bit more about it, I had realized myself that the clipboard overwriting was the actual means for getting the selected text into Alfred and not just a byproduct. Thanks for the explanation and for pointing out possible solutions. Unfortunately, my expertise does not currently go much beyond making simple changes to existing workflows, so I won't be able to create an improved version of this workflow. If someone else feels compelled to do so, it might be worthwhile to also include a check that ensures that the pasting does not happen before the Alfred bar is ready. The current workflow occasionally fails and just shows an empty Alfred bar. As far as I can tell, this primarily happens when the system resources are taxed.

On my machine, "r tomorrow at 10 am to do something" already works. Is it possible that you only tried it without the 'to'?

Would it be terribly difficult to implement support for the ISO date format (e.g., "2013-07-10 19:30")? I've come to love natural language date conversion tools that allow you to specify dates in a wide variety of ways (e.g., "2d 10:00", "friday in 2 weeks at noon", etc.) and then give you the corresponding standard ISO date, which is ideal for sorting and other purposes. I am using a modified version of Gabe Weatherhead's Keyboard Maestro macro, but Brett Terpstra's OS X service is also very good. The Reminders workflow is great in many ways, but for obvious reasons it lacks the power and flexibility of a full fledged date conversion system when it comes to parsing entered date information. If the workflow accepted dates in the ISO format, you could do the complex date translation externally and feed the result directly into the Reminders workflow. I can imagine that the date parsing code is already quite complex and you probably don't particularly enjoy touching it at this point, but if you could implement support for "r on 2013-07-11 14:15 to do something" that would be very useful.

I love the bundled "Show Alfred with Selected Text" workflow, there is only only thing that is really bugging me: whenever I invoke the workflow, the selected text is not only shown in Alfred but also put in the clipboard, which overwrites its previous content. Is there any way to prevent this behavior? I tried editing the workflow, but I only found the plist file with the settings and not the actual code of the workflow. I consider the current behavior a bug and would be very happy if it got fixed. If I am wrong and the current behavior is by design, would you consider implementing an option for turning off the clipboard overwriting part (or including two workflows, one for each behavior)? Thanks!

Initially, I thought the reminders were not created correctly for me because I did not receive notifications when they were due, even though they had due dates in Reminders.app. Then I realized that the "due date" that the workflow sets is different from the "remind me date", which is the one you can set if you create a reminder manually. I was not able to create reminders manually that had a "due date", only ones with the "remind me date". Long story short, the workflow can easily be modified to create reminders that properly trigger notifications. You just have to edit the "Run script" part of the workflow and change "due date" to "remind me date" in the following line: tell list reminderList to make new reminder with properties {name:theText, remind me date:theDate} Since I manage all my to dos in OmniFocus, I only use Reminders.app for short term reminders (e.g., call back person x in 30 minutes). Not having the alarm feature working kinda defeated the purpose of setting those reminders in the first place. Anyway, I am super thrilled that everything is working now for me. Thanks for your great work, Jack!