How to import entries with several emails to be readable by org-contacts and gnus

[DrWaleedAYousef]

For entries with several emails, they are imported, .e.g, as:

:EMAIL: email1
:EMAIL_WORK: email2

But this format is not searchable by org-contcts nor gnus. I think the only thing that work with both is to have the imported format like:

:EMAIL: email1, email2

How can I import in this format using org-vcard?

[flexibeast]

Unfortunately, that's not possible at the moment. Two possibilities than come to mind are:

• The code could be special-cased to not output an EMAIL property until parsing of an individual vCard has been completed, adding the values of other EMAIL* properties to the value of the EMAIL properties along the way.
• i could add a function org-vcard-combine-email-addresses which could be applied at any time, including after parsing (and by default if a user option org-vcard-combine-emails is t).

i think the second would be my preferred option. i'm certainly willing to add this, but am not sure when i'll get to it.

Also note that - and i would mention this in the docstring for org-vcard-combine-email-addresses - such a transformation is lossy, in that information about which email is personal, which is work, etc. would be lost, and therefore not available when exporting. i'm not sure how other vCard-handling software would behave in the presence of multiple EMAIL properties that aren't distinguished by an e.g. vCard 4.0 TYPE parameter.

All that said, i imagine a number of people might prefer that personal and work emails be kept separate; have you considered also asking the maintainers of org-contacts and Gnus whether they might support searching additional EMAIL properties?

[DrWaleedAYousef]

Unfortunately, that's not possible at the moment. Two possibilities than come to mind are:

• The code could be special-cased to not output an EMAIL property until parsing of an individual vCard has been completed, adding the values of other EMAIL* properties to the value of the EMAIL properties along the way.
• i could add a function org-vcard-combine-email-addresses which could be applied at any time, including after parsing (and by default if a user option org-vcard-combine-emails is t).

i think the second would be my preferred option. i'm certainly willing to add this, but am not sure when i'll get to it.

Also note that - and i would mention this in the docstring for org-vcard-combine-email-addresses - such a transformation is lossy, in that information about which email is personal, which is work, etc. would be lost, and therefore not available when exporting. i'm not sure how other vCard-handling software would behave in the presence of multiple EMAIL properties that aren't distinguished by an e.g. vCard 4.0 TYPE parameter.

Thanks so much for fast reply. Meanwhil, until you find the time to do this, I wrote this simple lisp function that converts the file to the desired format explained above (you can run it several times untill all email entries are lumped into one line or add a while loop inside the function):

(defun SingleEmail()
  (interactive)
  (goto-char 1)
  (while (search-forward-regexp ":EMAIL.*:" nil t)
    (replace-match ":EMAIL:" t nil))

  (goto-char 1)
  (while (search-forward-regexp ":EMAIL: \\(.*\\)
:EMAIL: \\(.*\\)
" nil t)
    (replace-match ":EMAIL: \\1, \\2
" t nil))

  )

All that said, i imagine a number of people might prefer that personal and work emails be kept separate; have you considered also asking the maintainers of org-contacts and Gnus whether they might support searching additional EMAIL properties?

This is the right thing to ask then. I will open an issue at org-contacts`.

Thanks so much once again.

[DrWaleedAYousef]

Meanwhile, I want to call your importing function in a single script, along with the above function. Is this the way that I can call your function (not the wrapper):

org-vcard-transfer-helper("~/.emacs.d.loadpath/McBackup.vcf" "~/.emacs.d.loadpath/Contacts-Imported.org" "flat" "en" 'import)

[DrWaleedAYousef]

I am not sure whether the problem I am posting now is related to the current issue or a new bug. The email property now is not imported from the vcf file to the org file, even if there is only a single contact that has a single email.