> For example, some people might want to cut the address part in
> (STREET,ZIPCODE,CITY,COUNTRY) whereas I think it's a burden, I just put
> a LOCATION property with all the address in it. In the end, it does not
> matter for org-contacts.
I use the splitted address version. And therefore I have one problem
which is however more general. I would like to group some properties.
So that I can have a properties group WORK and another group HOME.
* Friends
** Dave Null
:PROPERTIES:
:MOBILE: +49-1234-456789
:GROUP-WORK:
:EMAIL: d...@work.com
:LOCATION: …
:LANDLINE: +49-1234-567890
:GROUP-END:
:GROUP-HOME:
:EMAIL: d...@home.com
:LOCATION: …
:LANDLINE: +49-1234-987650
:GROUP-END:
:END:
I think this is not possible with the current design of the org
properties. Things like adding to persons /Dave Null (work)/ and
/Dave Null (home)/ or using WORK-EMAIL, HOME-EMAIL, … are not what I
would prefer.
My (at the moment best) idea to support grouping is:
* Friends
** Dave Null
:PROPERTIES:
:CONTACT: t
:MOBILE: +49-1234-456789
:END:
*** work
:PROPERTIES:
:EMAIL: d...@work.com
:LOCATION: …
:LANDLINE: +49-1234-567890
:END:
*** home
:PROPERTIES:
:EMAIL: d...@home.com
:LOCATION: …
:LANDLINE: +49-1234-987650
:END:
This would use all properties which are set directly as property of the
person as default and all others according to the requested group.
The absence of such groups is imho currently the main difference between
org-contacts and vcard/…
--
Michael
