Jump to content

chadv

Member
  • Content Count

    15
  • Joined

  • Last visited

About chadv

  • Rank
    Newbie

Contact Methods

  • Twitter
    @chadvonnau
  • Website URL
    http://vonnau.com
  1. 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.
  2. 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.
  3. +1 I would like to see this too.
  4. 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.
  5. @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.
  6. chadv

    possible php issue

    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. My solution was to renormalize to precomposed characters using the tool that @Andrew provided in this thread. php encode.php "$(./normalise -form NFC "{query}")" UPDATE: I had posted a different solution, using the iconv command, but it did not handle emoji. This latest solution handles everything I've tried so far.
  7. chadv

    possible php issue

    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"; ?> outputs: [INFO: alfred.workflow.input.scriptfilter] <items><item><title>alfred: é, file: &eacute;</title></item></items>
  8. chadv

    possible php issue

    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.
  9. 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.
  10. chadv

    possible php issue

    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.
  11. 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;
  12. 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.)
  13. Smart Quotes in the Copy to Clipboard task as well. Perhaps this is intentional? Figured I should report it anyway.
  14. 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.
×
×
  • Create New...