** (gnome-contacts:18058): WARNING **: contacts-linking.vala:118: Unable to set local ids when linking: Unknown error setting property ‘local-ids’: Changing the ‘local-ids’ property failed due to reaching the timeout.

I get that after some time.

This is the cause of this:

(e-addressbook-factory:18891): libebookbackendgoogle-DEBUG: unsupported vcard field: X-FOLKS-CONTACTS-IDS: alexander.larsson@gmail.com:http://www.google.com/m8/feeds/contacts/alexander.larsson%40gmail.com/full/7be96ec58db596db

The eds backend only supports single-value vcard attributes.

Created attachment 197031 [details] [review]
Fix e_vcard_unescape_string

Actually append unescaped chars too

Created attachment 197032 [details] [review]
google: Handle multivalue custom vcard attributes

We use this by vcard escaping the individual attributes and joining them
with a comma. Then we name the attribute with a -MULTIVALUE prefix in order
to not confuse things with previously stored single-value attributes.

Review of attachment 197031 [details] [review]:

Good catch. But still, does it make any sense to use g_utf8_get_char() there (in both places in the function)? If there will be a two-byte UTF-8 letter, then the 'p' variable will point on its first byte, then in the second step on the second byte of it, thus the result will be some kind of crap, isn't it? The g_utf8_get_char() does not validate its input, thus the result is fairly undefined in such cases. Feel free to correct me, if I overlooked anything.

True, the unichar and g_utf8_get_char stuff is nonsense. We should just use *p.

Review of attachment 197032 [details] [review]:

I think there cannot be used this:
> +		values = g_strsplit (value, ",", 0);
when the multivalues string will contain a comma, then it's escaped by e_vcard_escape_string in the second chunk, but the escaping means "just" adding a backslash in front of it, thus the strsplit will divide the string incorrectly, with the preceding part ending with a "significant" backslash.

Ah, true. We need a custom string-split then. But eds must have something like that somewhere?

Created attachment 197042 [details] [review]
google: Handle multivalue custom vcard attributes

We use this by vcard escaping the individual attributes and joining them
with a comma. Then we name the attribute with a -MULTIVALUE prefix in order
to not confuse things with previously stored single-value attributes.

Created attachment 197044 [details] [review]
Fix e_vcard_unescape_string

Actually append unescaped chars, and don't bother with broken
unicode char stuff.

Created attachment 197045 [details] [review]
google: Handle multivalue custom vcard attributes

We use this by vcard escaping the individual attributes and joining them
with a comma. Then we name the attribute with a -MULTIVALUE prefix in order
to not confuse things with previously stored single-value attributes.

Review of attachment 197044 [details] [review]:

The change makes sense, thanks. Let's commit this after the hard code freeze into both master and stable branches.

Review of attachment 197045 [details] [review]:

Looks good too, only use 'gchar' type instead of the 'char' type, and if you want to check for non-empty values, then do that on both places in the foreach_extended_props_cb(), maybe together with a check whether value != NULL. Just in case.

Created attachment 197052 [details] [review]
google: Handle multivalue custom vcard attributes

We use this by vcard escaping the individual attributes and joining them
with a comma. Then we name the attribute with a -MULTIVALUE prefix in order
to not confuse things with previously stored single-value attributes.

Review of attachment 197052 [details] [review]:

Looks good, thanks.

I got acks to commit the google patch, but the unescape fix is not yet commited.

(For the fix of e_vcard_unescape_string)

Created commit ff67849 in eds master (3.3.1+)
Created commit 68611bd in eds gnome-3-2 (3.2.1+)