chadv

+1 from me for multiple file drag. And +2 from this other thread: 

Thanks, @vitor. That's what I figured. It's sounding like my idea is not currently possible.

Thanks again. I tried: Get Path Basename > Arg and Vars  > Script Filter, but when I trigger the Script Filter, the upstream nodes don't run, and so the new variable does not seem to be available.

Thanks, @Stephen_C. I saw that node, but how would I wire it into the Placeholder Title of a Script Filter that is triggered by a keyword?

Hi,

I have a workflow with a File Picker variable in the Configuration Builder. I want to use the basename of this file in the Placeholder Title of a Script Filter. For example, if I choose "~/Documents/abc.txt" in the workflow configuration, I'd like the placeholder to say "Search abc.txt". Can it be done with a single user-configurable variable?

Thanks,

Chad

Hi, I'm really liking the new snippet functionality. I've found a specific case where auto-expand is not working: in a terminal window, immediately after a Ctrl-C, and with "expand snippets midstring" turned off. This is reproducible every time.

I use the query history feature a lot and, in my up-arrow frenzy, I often overshoot the entry I want. To get back to it, I clear out the alfred prompt and start from the beginning, going more slowly this time. It'd be nice if there was a way to go forwards through the history, so that I could correct my overshoot more easily.

My thought was that the down arrow would be a natural way to do this. I realize that the down arrow is currently used as a way to disengage query history mode, but the left and right arrow keys also do this, and it's rare that I want to disengage at all.

It works great, thank you!

+1 I would like to see this too.

When the Alfred prompt is open, and I type cmd-ctrl-space to bring up the character palette, it dismisses the Alfred prompt. This only happens with the small palette. If I switch to using the large palette (scroll to the top of the small palette and click the button with the asterisk), I can use cmd-ctrl-space without dismissing the Alfred prompt.

I'm running OS X 10.9.3 with Alfred 2.3 (264). My hotkey to bring up the Alfred prompt is cmd-space.

@Andrew's normalise utility works great, but I've since found that there is an alternative using the standard utility iconv with the (somewhat obscurely named)  UTF8-MAC encoding scheme:

@mklement0 Thanks for this tip. iconv works great for most strings, but I found that it does not work for some emoji. Pile of poo for instance. It gives the following error:

[ERROR: alfred.workflow.input.scriptfilter] Code 0: iconv: (stdin):1:4: cannot convert

It's a shame, because it's such an elegant solution, otherwise. For posterity, I'll add that this is happening in OS X 10.9.3 (libiconv 1.11), hopefully a future version fixes this.

@Andrew's script seems to be handling all emoji correctly. I'm going to use that for now.

I figured it out.

The issue is unicode normalization. Alfred is converting unicode input to decomposed characters.

In my test case Alfred is converting U+00E9 LATIN SMALL LETTER E WITH ACUTE into U+0065 LATIN SMALL LETTER E and U+0301 COMBINING ACUTE ACCENT.

php encode.php "$(./normalise -form NFC "{query}")"

I did more testing.

I switched to using an external php file. When the é is written in the external file, it encodes as expected. When the é is passed in from Alfred, it does not get encoded.

I no longer think this is specific to php. My current hunch is that something is happening to the é in Alfred's string handling, and php is receiving a non-standard é.

Here is the setup I used to test, and the output I received.

bash script, written directly in Alfred:

LANG=en_US.UTF-8 /usr/bin/php x.php "alfred: é";

x.php, external file:

<?php
$query = $argv[1].', file: é';
$encode = htmlentities(htmlentities($query));
echo "<items><item><title>$encode</title></item></items>\n";
?>

[INFO: alfred.workflow.input.scriptfilter] <items><item><title>alfred: é, file: &eacute;</title></item></items>

I found two apparent issues (PHP is not one of them):

1. You are calling htmlentities twice on the same piece of text. The first run produces "&é", which is valid. The second run re-encodes the ampersands and corrupts the output.
2. Your XML is missing the <?xml version="1.0" encoding="UTF-8"?> header. I'm not sure if that's part of the issue.

Hope this helps!

Hi Tyler, Thanks for taking the time to look at this.

I know about the double htmlentities(). That's intentional. When debug console output says &amp;&eacute;, it shows up in the Alfred prompt as &é, which is what I want.

I've tried adding the <?xml version="1.0" encoding="UTF-8"?>, but it makes no difference. I've also tried with an encoding value of ISO-8859-1, and it does not help either.

I'm at a loss for why this é isn't being encoded.

My initial suspicion was that it's related to the context that Alfred runs php in, since PHP's encoding functions change their behavior based on the system locale. However, based on the following tests, I'm not so sure:

• When I compare the output of phpinfo(), the command line context has the LANG var set to en_US.UTF-8, while in the alfred context, the LANG is not set.
• I tried adding $_ENV["LANG"] = "en_US.UTF-8" or putenv("LANG=en_US.UTF-8") or setlocale(LC_ALL, "en_US.UTF-8") to my script, but none of them make any difference.
• I followed the advice in this thread, to set the system LANG and LC_ALL vars using launchd. Alfred does pick up these changes, and they are reflected in the phpinfo() output, but the é remains unencoded.

One more interesting difference is with this function: iconv('UTF-8', 'ASCII//TRANSLIT', 'é'). On the command line, it outputs 'e, but in alfred, it outputs an empty string.

This description is really confusing, so maybe my response is off, but why not use the same script that opens text edit and selects the line # to also copy the title to the clipboard using Applescript's set the clipboard to ?

Thanks for your sugesstion, dfay. I'll probably wind up doing something like this, but using command line tools instead of Applescript and TextEdit.

I'm going to try to simplify my question to make it a little more clear what I'm looking for.

UPDATE: I found a workaround for my issue. The problem was with with unicode normalization. See the last post.

I'm getting unexpected results while running a php script in alfred. This is a reduced version of my script:

echo "<items><item><title>".htmlentities(htmlentities('&é'))."</title></item></items>\n";

When I run this from command line php, I get the expected result, with the é encoded into &eacute;

<items><item><title>&amp;&eacute;</title></item></items>

When I run this in an alfred workflow, the é is not encoded. Here's the debug console output:

[INFO: alfred.workflow.input.scriptfilter] <items><item><title>&amp;é</title></item></items>

If I replace the htmlentities() functions with &eacute;, it outputs correctly, so I don't think there's a problem with the console.

I'm running Alfred v2.3 (264) on OS X 10.9.3. I have not customized the php setup on my system.

I appreciate any help in getting to the bottom of this. Thanks.

One way would be to use a script. Here's a bash script you can use with the Run Script action:

# extract the filename from a full path
filename=$(basename "{query}");
# set the new destination
destination="/your/new/path/$filename";
# move the file
mv "{query}" $destination;
# open it
open $destination;

Hello,

Is there anyway to access the title value from the Copy to Clipboard task?

My results look like this:

<items>
  <item arg="/Users/chad/logins.txt:77">
    <title>alfredforums.com login: chadv</title>
    <subtitle>Open file.txt at line 77</subtitle>
  </item>
  <item arg="/Users/chad/logins.txt:99">
    <title>othersite.com login: chad</title>
    <subtitle>Open file.txt at line 99</subtitle>
  </item>
</items>

My primary action is an applescript that handles opening the file and selecting the line specified. I want to make a secondary action, accessible via modifier key, that copies the title value to the clipboard.

If this isn't possible natively, I can work around it with a script, but I wanted to ask first.

(EDIT: My original post was longer and rambling, I've reduced it for clarity.)

Smart Quotes in the Copy to Clipboard task as well. Perhaps this is intentional? Figured I should report it anyway.

The Editor for the Terminal Command task is set to use Smart Quotes by default.

I noticed this because of reading about a similar problem in another thread: http://www.alfredforum.com/topic/3612-applescript-workflows-failing-fixed-22-b239/

I'm running Alfred v2.3 (264) on OS X 10.9.3.