mklement0

Thanks, David - hadn't actually noticed - that's a promising start: I can see two approaches - which are not mutually exclusive: Approach 1: Have Alfred scan the code that was directly entered into a workflow step and match it against files in the workflow folder (other than the default files). Offer a button for each matching file (typically, there will be only *1*), or perhaps a pop-up list if there are too many. Clicking a button or selecting a list item would then open that file externally with its registered editor. Complementarily, offer the same list of matching files when control-clicking a workflow step from the outside (via a context menu). Approach 2: Inside a script-related workflow step, have Alfred offer the basic choice between inline code and a reference to an external file. In the latter case, restrict editing to a single command line that invokes the external file, and provide a button to open that file with its registered editor. (Conceivably, a custom language (interpreter) line could be added there as well - accompanied by a warning that such a workflow won't be portable.)To allow users to stay within Alfred's GUI in most cases, it would also be nice to be able to *create* an external file from within a script-related workflow step / its context menu. The appropriate filename extension could be derived from the chosen language (interpreter).

+1. Related to this request: http://www.alfredforum.com/topic/1803-edit-scripts-externally-with-auto-update/?hl=awkward#entry13595

+1. Note that, as of Alfred 2.0.3, on entering the Workflows tab, you can simply start typing to initiate a search, even though the cursor is not in the search field. More generally speaking, this works while the focus is on the *list* (as opposed to the workflow-definition pane), but is slightly awkward in that starting to type will simply *append* to the existing search field, if it isn't empty. An explicit way of placing the cursor in the search field - Cmd-F, as suggested - would definitely help.

I have a slightly more exotic use case: Sometimes I want to activate a given application (making it frontmost) while still having Alfred stay on top. This is useful for workflows that perform searches in other applications and want to use that application's GUI to provide rich, real-time feedback while searching (as opposed to the limited feedback that Alfred's results can provide). Case in point: I have an Evernote workflow where I type in a query and, via a script filter, have Evernote perform the same query as I type (the advantage of still using Alfred to formulate the query - rather than typing into Evernote directly - is that an Alfred script filter can apply convenient transformations that would be cumbersome to type into Evernote directly.) I know that, as a workaround, I can use AppleScript to activate an application and then re-invoke Alfred, but that (a) causes flickering and (b ) doesn't work when redisplaying Alfred with a remembered query.

Ultimately, the question is one of convenience and discoverability: Currently, you are forced to choose between two awkward alternatives: Either: deal with the limited editing features inside of Alfred or inconveniently copy code back and forth been Alfred and an external editor. Or: by and large bypass Alfred's GUI and invoke editing of external file's via the Finder. The latter technique is not even obvious to newcomers (right-click on workflow in list, select 'Show Finder', create file in that folder). A compromise would be to integrate a workflow's external files into Alfred's GUI by listing external files and offering to edit them with their respective editors offering to create new external files

Currently, you have to turn on "following" (being notified by email of new activity in) topics *manually*, It would be convenient to have an auto-follow feature - i.e., an automatic subscription to notifications of activity relating to a given topic - in response to either of the following actions: "liking" a topic or reply posting a reply I think these are reasonable defaults; personally, I've forgotten to turn on "following" on a number of occasions, mistakenly assuming it had been turned on for me.

The issues is not performance, but, as David said, consciously restricting the choices to those interpreters that come preinstalled on OS X. Of course, you can always Place the script in the language of your choice in your workflow's folder. Use an auxiliary bash script action or filter to invoke it. Bash script actions execute with the workflow's folder as the working folder, so any (executable) file placed there can simply be invoked by prefixing the filename with './' Many existing workflows already use this technique.

+1

+1 on being able to duplicate (and/or copy/paste) workflows *as a whole* (in addition to copying/pasting elements *inside* a workflow). Edit: Just noticed that duplicating workflows is also discussed here: http://www.alfredforum.com/topic/1017-feature-request-duplicate-workflow/?hl=duplicate As for grouping workflows: personally I find it sufficient to use shared keywords in the titles of related workflows; searching for (filtering by) such a shared keyword then in essence gives me a group view.

This may not be a bug, but it's worth noting: When you use open location to open a URL from inside an NSAppleScript action, it must be in the tell application "System Events" context, otherwise it will fail silently (as of Alfred 2.0.3 on OS X 10.8.3). For instance, to open URL "http://boston.com", you need to use the following: tell application "System Events" to open location "http://boston.com" # fails without `tell application "System Events" to` Note: If an action's sole purpose is to open a URL with the default handler, it is better to use the dedicated Open URL action type instead, which avoids this problem.

Thanks, Andrew. One final thought: another advantage to using an *element* to pass a value is that a CDATA element can then be used to enclose the value, obviating the need for XML encoding (which is not easy to come by in a bash script, for instance).

Thanks, David. An easy solution would be to allow a child *element* to act as an alternative to the `arg` *attribute* on the `<item>` elements, and to use that element's value unmodified (no normalization of whitespace), e.g.: <item> <arg>line 1 line 2</arg> <title>line 1 ...</title> <subtitle>multi-line test</subtitle> </item> Thanks for you workaround suggestion - it is preferable to mine in that no temp. files that could linger are involved. I've updated my original post and the linked-to demo workflow accordingly.

As of Alfred 2.0.3, it seems that passing multi-line text out from a script filter via the arg attribute (e.g., to the copy-to-clipboard action) is not supported: each newline is replaced with a space. I suspect this is a side effect of XML parsing, since the desired output value is stored in an XML attribute, and even though newlines are legal in attribute values, on passing the value out, XML parsers are expected to normalize the value by replacing all non-space whitespace characters with a space each, including \n (and \r\n) - see http://www.w3.org/TR/1998/REC-xml-19980210#AVNormalize Would be nice not to have this restriction, though, assuming my guess is correct, I'm not sure it's feasible with the current, XML-document-based approach. A workaround is below, but it is somewhat cumbersome. Workaround [updated on 2 May 2013 to incorporate David Ferguson's suggestion]: Inside the script filter, create a custom encoding where you replace newline chars. with a placeholder, e.g.: ⏎ Use the custom-encoded text as the value of the arg attribute. Add an intermediate script action that decodes the custom encoding by substituting newlines for the placeholders to restore the original value and then passes the restored value out.Sadly, since output from script actions cannot follow conditional paths based on keyboard modifiers, you'll have to duplicate the intermediate script action for every modifier combination you want to support, and attach the modifier-specific paths directly to the script filter. Download a demonstration workflow here: https://dl.dropboxusercontent.com/u/10047483/MultilineTextScriptFilterLimitationDemo.alfredworkflow Keyword "mt1" demonstrates the original limitation by attempting to copy a 2-line string passed from a script filter to the clipboard. Keyword "mt2" demonstrates the workaround. Workaround source code: Sample script-filter action (using /bin/bash: escape only backquotes, double quotes, backslashes, dollars): # Create sample multiline text. text=$'line 1\nline 2' # Derive a single-line representation for Alfred's result list. textForDisplay="${text//$'\n'/ ⏎ }" # Since linefeeds are inadvertently replaced by spaces when the value assigned to the `arg` attribute # is retrieved later, we assign a custom-encoded form of the output text in which we replace newlines # with placeholders. # In a subsequent, auxiliary script-action step we then perform unencoding to restore the original text. textEncoded=${text//$'\n'/⏎} cat <<EOF <?xml version="1.0"?> <items> <item arg="$textEncoded"> <title>$textForDisplay</title> <subtitle>Action to copy to clipboard and display notif.</subtitle> </item> </items> EOF Generic, directly reusable script action that unencodes (decodes) the custom encoding and relays the restored value (using /bin/bash; escape only backquotes, double quotes, backslashes, dollars): # Input is assumed to be custom-encoded text in which newlines have # been replaced with ⏎ chars. # We UNencode (decode) here in order to restore the newlines, and pass the # restored text out. v="{query}" echo -nE "${v//⏎/$'\n'}"

I like the idea, but why not take it further and - optionally - let *Alfred* handle filtering of the results of a script filter (rather than having to handle "sub-filtering" in your own code when a query is appended to the filter's keyword)? This feature, which could be a switch (option) on each script filter, could then provide a subordinate option to use fuzzy logic when sub-filtering.

Makes sense, _mk_ - I was seduced by the lure of the workaround solving three issues at once, but it turned out to be quite a bit more complex than I thought.

As it turns out, when you invoke a shell script via do shell script from an NSAppleScript action, UTF-8 encoding works as expected (no decomposition). Based on that, I came up with a workaround that ensures: that the user's locale is in effect in the bash script invoked that UTF-8 encoding works as expected - without the need for an external utility. that the entire query string is passed correctly to the script invoked as a single parameter - AppleScript takes care of escaping with quoted form of. The basic approach is to have a shell script invoked with a carefully crafted command line from a helper NSAppleScript action rather than directly. Because do shell script defaults to / as the working directory (rather than the workflow's folder), I had to determine the workflow's own folder beforehand, which turned out to be non-trivial. Aside: Does Alfred provide a way to for a workflow to query its own folder path? The workaround is demonstrated in the following workflow: https://dl.dropboxusercontent.com/u/10047483/encoding%20and%20locale%20in%20scripts%20-%20workaround%20demo.alfredworkflow Invoke it as follows, to see how an accented character is encoded and what locale is in effect: encodingandlocaledemo ü Given the amount of code involved, I'm not sure if the workaround is worth it, but perhaps there's something useful in there. Here's the code stored in the NSAppleScript action: on alfred_script(q) # -------- BEGIN: MUST BE CUSTOMIZED # * Create a bash script in this workflow's folder, # which will be invoked below. # IMPORTANT: use a UNIQUE NAME, such as created with `uuidgen`, e.g.: # "D0ACD509-E05A-4B5C-B45A-B2A7DECE0938.sh" # * Fill in this unique name on the next line. set shScriptName to "D0ACD509-E05A-4B5C-B45A-B2A7DECE0938.sh" # -------- END: MUST BE CUSTOMIZED # The workaround command string that ensures # - use of the current OS X user's locale # - normal (non-decomposed) UTF-8 encoding of non-ANSI characters. set workaroundCmd to "export LANG='" & user locale of (system info) & ".UTF-8'" # Determine the parent folder of where Alfred's preferences are stored. set prefsFolderParent to do shell script "defaults read ~/Library/Preferences/com.runningwithcrayons.Alfred-Preferences.plist syncfolder | sed -E 's:^~:'$HOME':'" # Determine THIS workflow's folder, via globbing and its unique script name. # Note: We canNOT use a workflow UID, because it changes on every export # and import. set thisFolder to do shell script "dirname \"$(echo " & quoted form of (prefsFolderParent & "/Alfred.alfredpreferences/workflows/user.workflow.") & "*/" & quoted form of shScriptName & ")\"" # Synthesize the cd command to change to this workflow's folder. set cdCmd to "cd " & quoted form of thisFolder # Construct the whole command line, passing q as a single, # properly escaped parameter. set cmdLine to workaroundCmd & "; " & cdCmd & "; /bin/bash ./" & shScriptName & " " & quoted form of q # Invoke the entire command line and pass out its stdout output. do shell script cmdLine end alfred_script

Thanks, _mk_ and Andrew. (As an aside: I should have searched the forums for "encoding"; however, I did search for utf (no quotes; rejected as too short), then "utf", "utf8", "utf-8" - none of which produced hits, even though they should.) I've updated my original post to (a) point out that the encoding issue is unrelated to the locale issue and ( b ) to include a workaround for the locale issue. To reiterate, add the following at the beginning of your script: export LANG="$(defaults read -g AppleLocale).UTF-8"

Bash scripts launched by Alfred in the context of workflows don't respect the OS X user's locale and instead default to the generic "C" locale. Alfred should use the same locale that is used when a user starts an interactive shell in Terminal.app (For instance, running locale in Terminal on my US-English system returns: LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL= ) To verify the problem, use the following test workflow: download and install https://dl.dropboxusercontent.com/u/10047483/localetest.alfredworkflow type localetest into Alfred, which will display the effective locale in large type To work around the problem, use the following at the beginning of your script: export LANG="$(defaults read -g AppleLocale).UTF-8" Possibly related [update: NOT related - see below]: non-ANSI characters are currently encoded in unexpected ways: In normal UTF-8 encoding, "ü" should be passed in (via {query}) as the following multi-byte sequence: expected: 0xc3 0xbc instead, Alfred currently passes: 0x75 0xcc 0x88 - 3(!) bytes

+1. (Sadly, this problem has been around a long time and only recently, after a long period of languishing, has received a bit of attention with the added option of escaping backslashes.) In particular, a single, aggregate option to escape the entire query for use in bash would be great. As of Alfred 2.0.3, one has to jump through the following hoops to achieve that: Opt to escape ONLY the following characters in Alfred:Backquotes Double Quotes Backslashes Dollars Use double-quoting to refer to query: "{query}" Incidentally, if you want to play interactively with how the shell escapes strings, use: printf '%q\n' 'inputString'. Similarly, Applescript's "quoted form of" can be used to experiment: quoted form of "Honey\\(`sweetie`), I'm $HOME." Here's a piece of text that can serve as test input to see if it can be passed through without any modification (e.g., by echoing {query} and redirecting to a file): It ain't "easy". a\b \\server a|b & more test: `ls`; also: $( ls ) $HOME, sweet \$HOME - \a!

Great workflow and surrounding ecosystem - I hope it catches on. Unfortunately, v1.1 is broken for me - see https://github.com/bpinto/hatmaker/issues/6 Also, I see that your own workflow is present both as the current (1.1) and the previous (1.0) version - both on http://www.alfredworkflow.com/ and when using `install hatmaker` in Alfred. Is that intentional, or should the old version just be removed? If intentional, then `install hatmaker` should display the version numbers so the entries can be distinguished.