Fix #887: Use ly:string-percent-encode for textedit URIs.

Fix #887: Use ly:string-percent-encode for textedit URIs.

* Add an overloaded instance of String_convert::bin2hex optimized for
  converting single bytes to hex.

* Add a new callback, ly:string-percent-encode, to be used for percent
  escaping paths in textedit URIs.  This does the following:

  - Leave unreserved characters in textedit URIs unescaped.  This
    includes 0-9, A-Z, a-z, and three punctuation characters (hyphen,
    underscore, and full-stop).

  - Leave the forward slash (/) unescaped, since it is used as a path
    delimiter.

  - Escape all other characters.  Don't check for a null byte, since
    those likely won't sneak into a full pathname.

* Use the callback function in the PS backend.

[lemzwerg, 2010-01-25 06:38:18]

http://codereview.appspot.com/193077/diff/1001/12
File lily/general-scheme.cc (right):

http://codereview.appspot.com/193077/diff/1001/12#newcode230
lily/general-scheme.cc:230: return ((c >= 0x2D && c <= 0x2F) // hyphen,
full-stop, and forward-slash
Wouldn't it be faster to use an array of `0' and `1', indexed by the character
code, instead of the many comparison operations?  E.g.

  escape_character[128] = { 0, 0, 0, ..., 1, 1, 0, ... }

[dak, 2010-01-25 09:28:36]

http://codereview.appspot.com/193077/diff/1001/12
File lily/general-scheme.cc (right):

http://codereview.appspot.com/193077/diff/1001/12#newcode230
lily/general-scheme.cc:230: return ((c >= 0x2D && c <= 0x2F) // hyphen,
full-stop, and forward-slash
On 2010/01/25 06:38:18, lemzwerg wrote:
> Wouldn't it be faster to use an array of `0' and `1', indexed by the character
> code, instead of the many comparison operations?  E.g.
> 
>   escape_character[128] = { 0, 0, 0, ..., 1, 1, 0, ... }
> 

Why not let the compiler bother about this?  Note that with current computer
architectures, a random memory access can easily take 10 times or more than a
comparison.

But I think that gcc is a compilation requirement anyway,
so it would just do to write:

switch (c) {
case '-':
case '.':
case '/':
case '0'...'9':
case 'A'...'Z':
case '_':
case 'a'...'z':
  return 1;
}
return 0;

This saves having to write any comment since the code is clear enough on its
own, and the compiler has all the info it needs to generate more concise code
than a human could.  In particular since the optimal code may well depend on the
target architecture.

[Patrick McCarty, 2010-01-28 08:05:44]

On 2010/01/25 09:28:36, dak wrote:
> http://codereview.appspot.com/193077/diff/1001/12
> File lily/general-scheme.cc (right):
> 
> http://codereview.appspot.com/193077/diff/1001/12#newcode230
> lily/general-scheme.cc:230: return ((c >= 0x2D && c <= 0x2F) // hyphen,
> full-stop, and forward-slash
> On 2010/01/25 06:38:18, lemzwerg wrote:
> > Wouldn't it be faster to use an array of `0' and `1', indexed by the
character
> > code, instead of the many comparison operations?  E.g.
> > 
> >   escape_character[128] = { 0, 0, 0, ..., 1, 1, 0, ... }
> > 
> 
> Why not let the compiler bother about this?  Note that with current computer
> architectures, a random memory access can easily take 10 times or more than a
> comparison.
> 
> But I think that gcc is a compilation requirement anyway,
> so it would just do to write:
> 
> switch (c) {
> case '-':
> case '.':
> case '/':
> case '0'...'9':
> case 'A'...'Z':
> case '_':
> case 'a'...'z':
>   return 1;
> }
> return 0;
> 
> This saves having to write any comment since the code is clear enough on its
> own, and the compiler has all the info it needs to generate more concise code
> than a human could.  In particular since the optimal code may well depend on
the
> target architecture.

Thank you Werner and David for your suggestions.

I decided to go with David's suggestion to use the GCC-specific syntax.  It
looks cleaner, and it reduces the need for code comments.

I'll let this patch sit here a while longer until I have a chance to do more
extensive testing.

Thanks,
Patrick