untidey

That's not exactly what I meant. A disconnect occurs between me and Alfred because I'm using an optional argument on the script filter out of necessity, but actually intend for their to be an argument in practical use. I type 'n' and the script filter shows a list of existing files. Then I either select one of the existing filenames or type a new string which gets passed to nvAlt and created as a new file. I need the optional argument in order to show the list of existing files to begin with. Alfred, quite rightly, matches the script filter and default results the moment I press 'n'. Now that I've actually thought about it, I see there's no reasonable alternative and given that my script filter results are prioritised it's really a non-issue anyway.

Having played around a bit more I see that there's no reasonable way around this for Alfred. Please close or delete this thread. ===== This thread describes my issue: http://www.alfredforum.com/topic/2924-hiding-default-results-from-script-filter-results/?p=17011 It would be quite excellent to have an option within a script filter to suppress any default results that may be matched by the keyword and arguments that match the script filter. I get default results mixed in with my script filter results which doesn't match my intention.

Having played around a bit more, I see your point. I'll just live with it.

I've created a script filter interface to my nvAlt notes. The keyword is 'n <optional argument>'. Pressing 'n<space>' shows all of my notes; any argument is used to filter the list. My problem is that default results, such as contacts and apps, are also added to Alfred's results list, not just what my script filter returns. Is there a way to hide these? Cheers Nick

Lovely. Looks good!

Sorry for the delayed response. I've actually stopped using this theme, but here's a theme URL with the approximate colour scheme. You can adjust fonts etc as required: http://cl.ly/2q2E1G330t1d

I wonder if Alfred could by taught to only fire off the script once a keypress timeout was met? So, instead of firing on immediate keypress, he waits for a very short time (30ms?) to see if another key has been pressed, only firing the script once no new keypress is registered. So, in the Avengers example, instead of firing on the press of 'a' it only fires once 'avengers' is fully typed, assuming you type 'avengers' quickly. Does that make sense? I couldn't find conclusive data on how quickly users typically type but did come across Jakob Nielsen's findings that a 100ms response time is still perceived as instantaneous. http://www.nngroup.com/articles/response-times-3-important-limits/

Thanks for the explanation Andrew. Makes perfect sense now that you mention it.

Seems b100 or b105 has added the ability to pass selected files as arguments to keywords. I think it still makes sense to add these options to keywords, unless there's a technical reason it can't be done? - Selection in OS X - OS X Clipboard contents

Cheers for the response. It may be a local issue. I tried reinstalling Alfred v1 and fn-up and down simply go to the start and end of my input line - same as with v2.

I see what you mean. Thanks Carlos. No way around in standard search results it seems... I'll go the file filter route.

Howdy all I'm wondering if anyone else has this issue, or not? I'd like to search for apps in /System/Library/CoreServices, in particular Folder Actions Setup, but Alfred can't find it. I've added the directory to my default results search scope and Alfred can find Finder, but not anything else. Spotlight can see the apps: Nick@MacBook[~]$ mdfind -name "Folder Actions" | grep "CoreServices" /System/Library/CoreServices/Folder Actions Setup.app /System/Library/CoreServices/Folder Actions Dispatcher.app Any thoughts would be appreciated! Cheers, Nick

Thanks bud, works for me too. Though I'm still wondering if my initial issue is an Alfred bug or not.

I'm running into trouble with using nvAlt's custom url scheme and want to understand if it's an Alfred issue or not. Given the following web search: This works great for single word queries - "nv lent" - but fails silently if there's a space in the query - "nv lent things" = fall over in a heap. nvAlt expects the 2nd query above to be encoded as "nvalt://lent%20things". Anyone know how Alfred should encode the query when "Encode spaces as +" isn't checked? EDIT: Now fixed in b137.

Cool thanks for the input. I found the cause of our issues. Non-interactive shells don't expand aliases by default. I'm now using the following: shopt -s expand_aliases source /Users/Nick/.bash_profile {query} 2>&1 & I needed to append the ampersand to the final line to get Sublime Text 2 to play nicely when called from the workflow though I don't understand why.

Hopefully there are some Bash scripting gurus out there who might be able to help. I'm trying to create a "Terminal Command" workflow that does the same as Alfred's built-in terminal shortcut without having to open an actual Terminal window. I want it to have access to my usual interactive, login shell environment. (Startup files: ~/.bash_profile, ~/.bash_aliases) I've linked a 'run script' action with Bash as the interpreter. I tried a basic script '{query}' which works but has no environment loaded. I tried: 'bash -l -c "{query}"' which, for reasons I can't fathom, doesn't load my environment in Alfred but does on the command line. I tried: export BASH_ENV='/Users/Nick/.bash_profile' bash -l -c "{query}" and seem to have created a self-replicating monster that is screwing up the Terminal and my system. >.< Any advice much appreciated! Thanks.

I have app matching set to 'Fuzzy capital letters' and fuzzy search works when searching for AppCleaner from the main dialog: But if I select an app (A Better Finder Rename) and select "Open With..." from the file actions dialog, fuzzy search doesn't work there: I have to type 'app' (or 'clea' even) to find AppCleaner. In Alfred v1, fuzzy search was available on this dialog. I would expect the Open With dialog to also adhere to the matching style set in the advanced settings tab.

Cheers mate. Figured you'd be swamped at the moment. Once the dust has settled I'll post afresh.

I know what you're saying I think and for this simple example that would work fine, but for anything more complex you'd lose access to all of Alfred's GUI goodness and power such as the different output options on each branch, modifier branches, etc. That's a lot of functionality to try and replicate, if it were even possible. I guess the real point I'm trying to make is that linking hotkeys to keywords seems fairly pointless at the moment and this is a suggestion of what might make it more useful. One thing the link currently allows you to do is pass the clipboard contents or selected text through to the keyword. I think keywords should just have 'selected text', 'clipboard' (and a new option 'selected finder files') as argument options directly anyway. Given the way Alfred currently renders the hotkey with argument to keyword link (which looks quite strange), it seems that this particular part of workflows is something Andrew's yet to look at. All the more reason to discuss possibilities before any work is done on it.

Is it as simple as adding '/usr/bin/osascript' as an interpreter and wiring it up?

I like a lot of those ideas, in particular: - input buffer for script filters - JSON encoding of script filter output - selected text or clipboard argument for hotkeys and while I the topic of the third: 'selected text', 'clipboard' and 'selected text OR clipboard' options for keyword inputs 'selected finder items' arguments for hotkeys and keywords

I'm curious if there's a use case people see for currently being able to link hotkeys to keyword inputs in a workflow? At present, the handling seems a bit random. I know Andrew is still expecting workflows to evolve, I'm just trying to get my head around various possibilities as we go. On one level hotkeys seem like just another input. But being able to link them to multiple keyword inputs might provide a nice facility to use hotkeys to bring up a list of the keywords to which they are linked. For example, imagine the following, reasonably contrived scenario: If we could link the hotkey to all three keyword inputs, then pressing the hotkey could bring up a results list containing the three items: Toggle Hide Show Library Empty Trash one of which you select to process.

EDIT: I was having trouble with Page Up/Down support in long results listings due to custom keybindings changes in the file: ~/Library/KeyBindings/DefaultKeyBinding.dict which had remapped Page Up and Down from (I think) "scrollPageUp/Down" to "pageUp/Down" which caused problems with Alfred's recognition of the keys.

I encountered that last night actually. Not pleasant.

Hotkeys allow for the following arguments: selected text; clipboard contents. Keywords allow for manually typed arguments. Neither allow the selected finder items to be passed to a workflow, one must use the hotkey or keyword assigned as part of the file actions preferences. I propose adding "Selected finder items" as an allowable argument to hotkeys and keywords and adding the selected text and clipboard contents options to keyword arguments. EDIT: Seems b100 or b105 has added the ability to pass selected files as arguments to keywords. I think it still makes sense to add these options to keywords, unless there's a technical reason it can't be done? - Selection in OS X - OS X Clipboard contents