lilyball Posted April 2, 2013 Share Posted April 2, 2013 I have a workflow that can actually tell the difference between composed and decomposed characters in the query string. The script filter looks like ./command {query} If I run my script filter with the single character U+00E9 LATIN SMALL LETTER E WITH ACUTE, it actually receives the characters U+0065 LATIN SMALL LETTER E followed by U+0301 COMBINING ACUTE ACCENT. Link to comment
jdfwarrior Posted April 8, 2013 Share Posted April 8, 2013 I have a workflow that can actually tell the difference between composed and decomposed characters in the query string. The script filter looks like ./command {query} If I run my script filter with the single character U+00E9 LATIN SMALL LETTER E WITH ACUTE, it actually receives the characters U+0065 LATIN SMALL LETTER E followed by U+0301 COMBINING ACUTE ACCENT. Sorry for the delayed response. This is a known issue right now. Andrew attempted to provide some input normalization functions during the v2 beta period. After discovering this issue, we spent quite a while attempting to troubleshoot the issue and find a solution. This option was later removed and marked as something for Andrew to investigate again later. Link to comment
lilyball Posted April 8, 2013 Author Share Posted April 8, 2013 Well, if you want to see a workflow that cares, I have one that provides information about unicode characters. You can download the workflow here, and invoke it with `char é`. Link to comment
jdfwarrior Posted April 8, 2013 Share Posted April 8, 2013 Well, if you want to see a workflow that cares, I have one that provides information about unicode characters. You can download the workflow here, and invoke it with `char é`. I promise, I spent a good while testing it before. I made several workflows, ran tests from within Alfred, from CodeRunner, from the terminal, etc. Link to comment
Andrew Posted April 8, 2013 Share Posted April 8, 2013 During development, I spend a good amount of time playing with Unicode. Alfred uses NSTask which converts arguments using [NSString fileSystemRepresentation]. Internally, this decomposes the UTF-8 to suit the filesystem. Cut a long story and significant investigation short, this decomposition is outside of Alfred's control without a risky overhaul to NSTask / NSString. Your best bet is to re-normalise the UTF-8 into the form you need before using it. Link to comment
lilyball Posted April 8, 2013 Author Share Posted April 8, 2013 During development, I spend a good amount of time playing with Unicode. Alfred uses NSTask which converts arguments using [NSString fileSystemRepresentation]. Internally, this decomposes the UTF-8 to suit the filesystem. Cut a long story and significant investigation short, this decomposition is outside of Alfred's control without a risky overhaul to NSTask / NSString. Your best bet is to re-normalise the UTF-8 into the form you need before using it. NSTask calls fileSystemRepresentation for arbitrary arguments? That's wacky. And in my case, the workflow displays information about the unicode characters. It doesn't "want" one particular normalization, it just displays different output for the different normalizations, and this means if I ever actually need to know whether a sequence is composed or decomposed, I'll have to use a different tool. Oh well. Link to comment
Andrew Posted April 8, 2013 Share Posted April 8, 2013 NSTask calls fileSystemRepresentation for arbitrary arguments? That's wacky. It's extremely wacky and very annoying - there is almost no information on this whatsoever! One of the beta releases would allow you to re-normalise {query} to any form you chose but as soon as this was passed to NSTask, it would re-normalise and decomposed. Being naughty and swizzling a few methods managed to 'fix it', but who knows what sort of havoc this could cause which is why I call it a "risky" fix and it was removed. Link to comment
lilyball Posted April 8, 2013 Author Share Posted April 8, 2013 It's extremely wacky and very annoying - there is almost no information on this whatsoever! One of the beta releases would allow you to re-normalise {query} to any form you chose but as soon as this was passed to NSTask, it would re-normalise and decomposed. Being naughty and swizzling a few methods managed to 'fix it', but who knows what sort of havoc this could cause which is why I call it a "risky" fix and it was removed. Did you file a radar on this? If so, what's the number? Link to comment
Andrew Posted April 8, 2013 Share Posted April 8, 2013 Did you file a radar on this? If so, what's the number? I didn't, because I didn't think it was a bug... just a consequence of using NSTask. Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now