Andrew

Yep, absolutely sure - I'm looking at the v1 vs v2 clipboard searching code right now and they are both limited to 50 + searching. There isn't a way to increase this cap as it stands. Having said that, if you use Alfred's [persistent] snippets, you can put as many as you like in there and scroll through all of those.

Alfred v1 only showed 50 items too, same as v2... and you needed to search to get to older items.

v2's clipboard history searching should work the same as v1. What behaviour exactly are you looking to get back?

This should fixed in 2.0.3

This is actually something I've recently started to look into, I'm likely going to move that back from Noted into Bugs at some point

Just a quick update to say that from 2.0.3, the fallbacks will show in this scenario as I agree that Alfred should do what he always does when no results are found

I'll add in escaping for \ for the next release

It shouldn't matter that the workflow is a bit buried in the results as you don't need to 'action' the workflow before you can use it... if you just continue to type e.g. show Alfred and just type #f00, the other results will soon disappear when they are no longer relevant.

Alfred only displays 50 of the latest items to prevent the memory usage from exploding. Simply type to filter the clipboard history back to the oldest stored date (this is in fact the best way to get to any of your clipboard history, even recent things). Cheers, Andrew

The background image changing is simply designed to see your theme against different backgrounds to make sure it works, so not persistent in any way. I'm moving this to closed as I want to keep the bug forum focused

Alfred isn't doing anything actively to spin your drives up, so there must be a roll-on effect happening somewhere (e.g. metadata query). You could always try restarting Alfred once the drives are connected to just see if there is different behaviour?

You may find this is caused by the eject keywords and outside of Alfred's control - try disabling the eject keywords in Alfred's features > system prefs. If this is the case, try changing the eject scope to "Mounts in /Volumes" instead of the other two.

To start with, I want to add duplicate at the workflow level, but eventually, I want to make it significantly easier to play around with workflow objects themselves (i.e. copy / paste / duplicate within a workflow).

I don't have that folder in Xcode - what did you install to get it?

Just a quick note to say that in the next release (after 2.0.2), the item UID attribute will be optional. You only need to populate it if you want Alfred to learn and order your results (an example of this would be something similar to Alfred's open / find keywords where he learns the selected file for latter ordering). If you leave the UID attribute empty, a UUID is used instead which means Alfred won't learn the ordering so always show results in the XML order.

It's the latency you may see as different - the 'compiled' option will keep the AppleScript pre-compiled in memory and run immediately... so AppleScript will start to run in a fraction of a second after asking it to. Without compiling (or using Run Script with osascript), it has to compile the script before running it. On modern Macs, this is still pretty fast though.

A script filter is more designed for live feedback into Alfred and is called as you type. You would be better using a keyword to script. Take a look at the Workflow Templates > Essentials > Keyword to Script

Essentially, the Run NSAppleScript set to 'compiled' will be the fastest, and for fast non-processing type AppleScripts, it is perfect BUT this will make Alfred use a little more memory. NSAppleScript will also allow you to easily show dialogs from your AppleScript as it doesn't have the same security restrictions as osascript. Due to the nature of NSAppleScript, you need to wrap your AppleScript in on alfred_script(q) and end alfred_script. Using a Run Script with osascript runs the AppleScript in the background which will allow a script to take quite some time to run and not block Alfred (i.e. you can use Alfred while something is still running in the background from a previous workflow). AppleScript can be pasted raw into this and doesn't need any special wrapping.

I didn't, because I didn't think it was a bug... just a consequence of using NSTask.

This is going to be improved in a future release

It's extremely wacky and very annoying - there is almost no information on this whatsoever! One of the beta releases would allow you to re-normalise {query} to any form you chose but as soon as this was passed to NSTask, it would re-normalise and decomposed. Being naughty and swizzling a few methods managed to 'fix it', but who knows what sort of havoc this could cause which is why I call it a "risky" fix and it was removed.

Once you see [Accepted] in the title, it's been moved into my bug tracker so no need to 'up-vote' a bug. The code for this has already been fixed for 2.0.3.

During development, I spend a good amount of time playing with Unicode. Alfred uses NSTask which converts arguments using [NSString fileSystemRepresentation]. Internally, this decomposes the UTF-8 to suit the filesystem. Cut a long story and significant investigation short, this decomposition is outside of Alfred's control without a risky overhaul to NSTask / NSString. Your best bet is to re-normalise the UTF-8 into the form you need before using it.

It doesn't look like you are a Powerpack user, so could you explain how you are trying to run the AppleScript (or fill in your Powerpack details in your forum profile). Cheers, Andrew

You actually don't need a workflow for this - in Alfred's Features > iTunes > Keywords you can configure the keywords for this and enable them in the default results