Andrew

@deanishe one of my notes in the ticket is for more granular logging levels. I specifically wrote to make the Script Filter JSON/XML output as finest (i.e. least important), as while messing about with the screenshot above, I ended up making the output empty so I could actually see if things were going on

@deanishe I've added in a few extra bits of debugger output to the script filter for the next release, so now you see the argument being queued (which can stack up depending on the selected queue mode), and the argument used with relation to the script output (the actual argument used when running the script). I've also added a ticket to look at improving the debugger generally, increased info etc. Cheers, Andrew

@vitor if it's only occasionally, why not create a super simple workflow with a file filter wired into a run script to do exactly this?

@deanishe The debugger "All Information" currently shows what's being passed out of objects, so when I connect a keyword to a script filter, I see the output from the keyword being passed to the connected script filter. Where are you not seeing logging? I'm happy to take a fresh look at the debugger and add more info where useful

@deanishe It's unlikely I'll be able to do anything to fix the Sublime Text behaviour in this case - I'm more interested in a script generally waiting on STDIN from blocking that workflow continuing.

@vitor @deanishe So I've been playing with this a little, and have managed to reproduce it with a simple Run Script set to PHP setup to read from STDIN. By Alfred cleanly closing STDIN before reading to the end of the STDOUT buffer, it prevents the PHP Run Script from waiting indefinitely. I've just done a 3.4 b834 pre-release which includes this fix, and I'd appreciate if you could verify this change a bit holistically for normal workflow operation (as it's part of Alfred's fundamental framework). Let me know how you get on Cheers, Andrew

@Danny Nemer You can actually remove individual items from the clipboard history from within Alfred's history viewer. Select the item you want to remove and use fn+backspace. Cheers, Andrew

@GuiB It's always going to work on (initially) hovered object, but it should work when using the arrow keys... which it's not. I'll make sure that's fixed before the general release.

@Hevisko if you update to the latest pre-release from Alfred's update prefs, this should now be fixed Cheers, Andrew

@GuiB I've actually already made a few tweaks for the next build where you can leave this disabled and just hold the options key when you want to see the alignment guides. This will be in pre-release later today, or possibly tomorrow. Cheers, Andrew

@deanishe I've actually already sorted that for the next release - and "substract" in the date arithmetic bit

Ah thanks, typo, should be "was was was"

If you update to the latest pre-release, the snippet trigger is now in - and yep, it means type some text in any app and away you go

@derBingle If you update to the b837 pre-release, you can now enable this by right clicking in the canvas and selecting in the Options sub-menu

@kballard this is now sorted if you update to the b837 pre-release. I'm still tempted in raising a ticket with Apple though, as it doesn't feel right that the clip counter can happen before the clip changes are seen as complete. Cheers, Andrew

@GuiB This option is now available under the "Run Behaviour" button within the Script Filter workflow object config sheet if you update to the b837 pre-release

@vitor There is a new Snippet Trigger workflow object coming very soon which carries the same "focused app" variable option that hotkeys do. This will essentially allow you to dynamically create an auto expanding text snippet based on the currently focused app

@GuiB I've added a ticket to look into this. An option may be added as an option under the "Run Behaviour" allowing all typed characters to be preserved (defaulting to the fixed current behaviour). Cheers, Andrew

@GuiB @deanishe Interesting, and something I haven't looked at for quite some time. Firstly, it's correct that Alfred is trying to make things more efficient and prevent scripts from running unnecessarily. I've actually identified a little bug where it's trimming the query instead of trimming the trailing spaces, which is why you're seeing that odd leading behaviour. I've just fixed that. As this is the first time this has come up, could I ask the use case for needing the spaces as being significant? It's possible I may remove the trimming altogether rather than adding an option to make spaces significant. Cheers, Andrew

@kballard hmm, I had (wrongly?) assumed that this would have either been wrapped in a single pasteboard "transaction", or clearContents would have adjusted the clipboard change count (i.e. clipboard changed to empty), then writeObjects would have adjusted it too (i.e. changed to contents). I've had a bit of a play with this and I can comfortably ignore clip counter changes until there are types available. Thanks for highlighting this - I'll have this fixed in the next 3.4 pre-release Cheers, Andrew

Alfred watches the pasteboard change count. It looks like the change count is increased, but nothing is in the clipboard (yet), then a short period later, the data is defined in the clipboard. There is no way to achieve this using the standard pasteboard API, which is why you don't see this behaviour with other apps, so I suspect they may be doing something sketchy behind the scenes. I'm not sure I want to add a fudge into Alfred to cater for this one specific case, but I will raise a bug against Maps.app. Cheers, Andrew

@kballard I've just looked into this and there is definitely something odd going on with Maps.app which initially appears to be a bug. When copying something from Maps.app, there are no types reported in the clipboard. For example, if I copy a URL from Safari (or any other Mac app), I see this: TYPES: ( "dyn.ah62d4rv4gu8zs3pcnzme2641rf4guzdmsv0gn64uqm10c6xenv61a3k", WebURLsWithTitlesPboardType, "dyn.ah62d4rv4gu8yc6durvwwaznwmuuha2pxsvw0e55bsmwca7d3sbwu", "Apple URL pasteboard type", "public.url", "CorePasteboardFlavorType 0x75726C20", "public.url-name", "CorePasteboardFlavorType 0x75726C6E", "public.utf8-plain-text", NSStringPboardType ) And this is what I see when copying from Maps.app using cmd+c: TYPES: ( ) ... But doing a subsequent paste of this copy to e.g. TextEdit, it pastes a stack of stuff. I haven't finished looking at this, but it looks like Maps.app is doing something fudgy and non-standard to get the data / URL into the clipboard. This would explain why there is different behaviour in Maps.app vs other apps. Andrew

Decided to sneak this into the upcoming 3.4 release, this will be in the next pre-release (probably tomorrow), available as an option from the popup menu on the workflow editor canvas It essentially shows guides for the object you are currently interacting with (hover / drag). Cheers, Andrew

@vitor not really related - that post is for Alfred v2 where workflow layout was fixed to 4 pre-defined columns. I've worked on auto layout systems in the past, and these are hardly ever effective, as while you can do some automatic arbitrary layout, you can never get in the head of the user and how they actually want it laid out. @derBingle I'll add a ticket for this, as it's actually something I've thought about a few times in the past Cheers, Andrew

@fakepop oops, thanks! If you update to b834, this is now fixed properly.