Semicolon in multiline fields are escaped during the export.

[sg2002]

I know that multiline fields are not really supported for now, but there's something easy that would at least make them go in and out fine - those escape slashes before each semicolon should be removed.

Here's a modified vcard from earlier: BEGIN:VCARD VERSION:2.1 N;CHARSET=UTF-8:Пупкин;Василий ADR;HOME:;;1600 Pennsylvania Ave NW;Washington;DC;20500;USA END:VCARD

After we import and export it back we get: BEGIN:VCARD VERSION:2.1 FN;CHARSET=UTF-8:Пупкин\;Василий N;CHARSET=UTF-8: VERSION:2.1 N;CHARSET=UTF-8:Пупкин\;Василий ADR;HOME;CHARSET=UTF-8:\;\;1600 Pennsylvania Ave NW\;Washington\;DC\;20500\;USA END:VCARD

Also note extra N and Version fields. Version appears only if exporting from flat style. They didn't break anything for me, but it's still worth noting.

[flexibeast]

The escaping of semicolons is partly by design, as it's required by the vCard standards. The vCard 2.1 specification states:

"Compound property values are property values that also make use of the Semi-colon, field delimiter to separate positional components of the value. For example, the Name property is made up of the Family Name, Given Name, etc. components. A Semi-colon in a component of a compound property value must be escaped with a Backslash character (ASCII 92)."

Having said that, you are of course correct that the escaping being done here is incorrect! i'll work on fixing that asap.

The other issues you note are odd; i can reproduce them here, using the example you've provided, but they don't appear with my test data. i'll look into what's going on here in any case.

Thanks for your reports!

[flexibeast]

Oh and just to make sure we're on the same page regarding 'multiline': in the vCard context, a multiline property value is one that has embedded newlines, not one that has multiple components. So:

ADR:1 Test Lane;Someplace;Somewhere

is not 'multiline', but:

ADR:1 Test Lane;
    Someplace;
    Somewhere

is.

[flexibeast]

i believe the issues you've raised above are now fixed; could you please confirm?

[sg2002]

Extra version and name were fixed.

Slashes before semicolons on the other hand, are still there.

Also I noticed another thing from an earlier bug - even though export and import are appended in the same buffer, empty extra buffers are still created.

[flexibeast]

Okay, take two on the attempt to stop the incorrect escaping of semicolons .... Could you please let me know if it now works for you? Note, though, that if you import and then immediately export the above vCard, there will be an escaped semicolon in the value of the FN property; the FN property can't have compound values, so any semicolons in the value of that property are assumed to not be a component separator, but part of the value itself.

The problem of extra empty buffers should also be fixed; and i've added a new setting, org-vcard-append-to-existing-export-buffer.

[sg2002]

Yep, now it's working fine.

As for semicolons before FN - import uses FN as the main value for name. If you export, then import, you get Doe\;John. I guess N should be the main value for name, or FN should be transformed to something like "First Last" format.

Thanks for you hard work, I'm so glad that org-vcard is now usable for me in my normal use cycle.

As for further development, I have a couple enhancement suggestions. After doing import and export a couple of dozen times, I think that some parameters in export and import commands should not be asked all the time. Version should be determined by the value in vcard, then by the default value variable, and if you really want to specify it in a specific case, it should go with a prefix argument. The same thing with style, if org-vcard-default-style is set, style should not be asked. Also, maybe there should be separate functions for buffers, regions and files.

[flexibeast]

Glad it's now working fine for you. :-)

Re. your other points:

If you export, then import, you get Doe\;John.

Yep, i noted that in my previous comment. :-)

I guess N should be the main value for name

The problem is, the property that a given system uses as its primary "name" property varies. In the systems that you're using, N is used as the primary "name" property. In the systems that i'm using, FN is used as the primary "name" property. So it seems to me the best thing to do in the case of org-vcard would be to make this user-configurable; created issue #15.

or FN should be transformed to something like "First Last" format.

Unfortunately it's not that simple. :-) This post explains why. (i refer to this URL in comments in the org-vcard source)

Thanks for you hard work, I'm so glad that org-vcard is now usable for me in my normal use cycle.

You're most welcome! Thank you for providing useful feedback, and for testing my changes. :-)

Version should be determined by the value in vcard

Agreed. This is already on the TODO list.

then by the default value variable, and if you really want to specify it in a specific case, it should go with a prefix argument. The same thing with style, if org-vcard-default-style is set, style should not be asked.

nod Also agreed, overall. However, i'm not sure about the prefix argument being used for version rather than style .... i think that's probably the way to go, assuming that people are probably more likely to want a different version rather than a different style, but i'd like to think about this some more.

Also, maybe there should be separate functions for buffers, regions and files.

It's certainly easy enough for me to create wrapper interactive functions around the existing interactive export and import functions. But, are you thinking of a separate function for each possible combination, e.g.:

• Export
  • file -> file
  • file -> buffer
  • buffer -> file
  • buffer -> buffer
  • region -> file
  • region -> buffer
• Import
  • file -> file [etc]

If so, that seems unwieldy to me. i'll think about it some more before making any decision on this.

Thanks again!

[sg2002]

Oh, I totally forgot about there being multiple import locations... Yeah, then it's not a good idea.

Know about the name thing, so yeah it should be user configurable.

As for prefix, I don't get, what would be the problem with using two different prefixes, one for version, one for style, maybe even one for version and style?

[flexibeast]

As for prefix, I don't get, what would be the problem with using two different prefixes, one for version, one for style, maybe even one for version and style?

Oh! Sorry, it seems i've misunderstood you. i thought you were suggesting that the prefix argument would be a version number; but i think you're actually suggesting that the prefix argument would be e.g. 'v' (for version), 's' (for style) or 'b' (for both version and style), and that this argument would be used to determine whether or not to prompt the user for version number, style etc.? If so, then yes, i'm definitely happy to implement that. :-)

[flexibeast]

i just discovered that prefix arguments can only be numeric .... Would 1 = prompt for version, 2 = prompt for language, 3 = prompt for style, 4 = prompt for version+language+style be what you're after?

[sg2002]

I think it's best to go with emacs conventions here, something lilke: C-u aka (4) - language C-u C-u aka (16) - version

And some other for more complex cases.

[flexibeast]

i think you're right that it would be preferable to go with Emacs conventions, but the problem is that doing so creates an issue around what prompts to prioritise. Some users might prefer that a single C-u prompts for version, C-u C-u prompts for language, C-u C-u C-u prompts for style; others might prefer that C-u prompts for language, C-u C-u prompts for version+language+style; and so on. Even if i make this user-configurable, i'd rather users didn't have to decide which prompt to relegate to C-u C-u C-u C-u or something. Whereas with a nil or single-digit argument (which i could also make user-configurable), user keypresses are limited to either C-u or C-u .

Does that sound reasonable?